Cadeado Mutex: o que significa" bloqueio"?
estive a ler sobre multithreading e acesso a recursos partilhados e um dos muitos (para mim) novos conceitos é o mutex lock. O que eu não consigo descobrir é o que está realmente acontecendo com o tópico que encontra uma "seção crítica" está bloqueado. Diz em muitos lugares que o fio fica "bloqueado", mas o que significa isso? Está suspensa e continuará quando a fechadura for levantada? Ou irá tentar novamente na próxima iteração do"run loop"?
a razão pela qual pergunto, é porque eu quero ter o sistema fornecido eventos (mouse, teclado, etc.), que (aparentemente) são entregues no fio principal, para ser manuseado em uma parte muito específica no ciclo de execução do meu fio secundário. Seja qual for o evento entregue, faço fila na minha própria infra-estrutura de dados. Obviamente, a estrutura de dados precisa de uma fechadura mutex porque está a ser modificada por ambos os fios. A peça de quebra-cabeça em falta é: o que acontece quando um evento é entregue em uma função na linha principal, eu quero colocá-lo na fila, mas a fila está trancada? O tópico principal será suspenso, ou irá simplesmente saltar sobre a secção trancada e sair do escopo (perder o evento)?
4 answers
Bloqueado significa que a execução fica presa lá; geralmente, o fio é colocado para dormir pelo sistema e produz o processador para outro fio. Quando um thread é bloqueado tentando adquirir um mutex, a execução recomeça quando o mutex é liberado, embora o thread pode bloquear novamente se outro thread agarra o mutex antes que ele possa.
Geralmente existe uma operação de bloqueio que pega o mutex, se possível, e se não, irá retornar um erro. Mas vais ter de te mudar. o evento actual nessa fila. Além disso, se você atrasar a mudança dos eventos para o tópico onde eles são tratados, a aplicação ficará sem resposta, independentemente.
Uma fila é, na verdade, um caso em que se pode escapar sem usar um mutex. Por exemplo, Mac OS X (e possivelmente também iOS) fornece as funções OSAtomicEnqueue() e OSAtomicDequeue() (ver man atomic ou <libkern/OSAtomic.h>) que exploram operações atômicas específicas do processador para evitar o uso de um bloqueio.
A maneira mais simples de pensar nisso é que o fio bloqueado é colocado em um estado de espera ("dormindo") até que o mutex é liberado pela thread segurando-o. Nesse ponto, o sistema operacional "acordará" um dos fios esperando o mutex e deixá-lo-á adquiri-lo e continuar. É como se o SO simplesmente coloca o fio bloqueado em uma prateleira até que ele tem a coisa que precisa para continuar. Até o SO tirar o fio da prateleira, não está a fazer nada. A implementação exacta ... thread começa a seguir, se todos eles são acordados ou eles estão em fila de espera -- vai depender de seu SO e que linguagem/framework você está usando.
Bloquear significa esperar {[[5]} - assumir sobre um sistema SMP um thread B quer adquirir um spinlock mantido por algum outro thread A. Um dos mecanismos é para desactiva a preempção e continua a rodar no processador, a menos que o B O Receba. Outro mecanismo provavelmente, um eficiente, é permitir que outros threads para usar processador, no caso de B não obtê-lo em tentativas fáceis. Portanto, agendamos o thread B (como a preempção está ativada) e damos o processador para algum outro thread C. Neste caso, o thread B apenas espera na fila do scheduler e volta com a sua vez. Entenda que B não está dormindo apenas esperando passivamente em vez de ocupado-esperar e queimar ciclos de processamento. Nos sistemas BSD e Solaris existem estruturas de dados como catraca para implementar esta situação.
Bloquear significa dormir {[[5]} - Se o tópico B tivesse feito uma chamada do sistema como read () à espera de dados do 'socket' de rede, não poderá prosseguir até o obter. Portanto, alguns textos casualmente usam o termo bloqueio como"... bloqueada por E / S "ou"... in blocking system call". Na verdade, o fio B está a dormir. Existem estruturas de dados específicas conhecidas como filas de sono {[[4]} - como salas de espera de luxo em portas de ar: -). O fio será acordado quando o OS detectar a disponibilidade de dados, muito parecido com um atendente da sala de espera.
Mas, por exemplo, em blocos sincronizados Java, seu thread vai parar até que ele seja capaz de adquirir o monitor (mutex, lock). A interface java.util.concurrent.locks.Lock descreve os objectos de bloqueio que têm mais flexibilidade em termos de aquisição de bloqueio.