No nível teórico, eles não são diferentes semanticamente. Você pode implementar um mutex usando semáforos ou vice-versa (veja aqui um exemplo). Na prática, a implementação é diferente e eles oferecem serviços ligeiramente diferentes.
A diferença prática (em termos de serviços do sistema que os cerca) é que a implementação de um mutex visa ser um mecanismo de sincronização mais leve. No oráculo, os mutexes são conhecidos como trincos e os semáforos são conhecidos como esperas .
No nível mais baixo, eles usam algum tipo de teste atômico e mecanismo definido . Isso lê o valor atual de um local de memória, calcula algum tipo de condicional e grava um valor nesse local em uma única instrução que não pode ser interrompida . Isso significa que você pode adquirir um mutex e testar para ver se mais alguém o teve antes de você.
Uma implementação típica do mutex possui um processo ou thread executando a instrução test-and-set e avaliando se alguma outra coisa configurou o mutex. Um ponto importante aqui é que não há interação com o agendador , portanto, não temos idéia (e não nos importamos) de quem definiu o bloqueio. Em seguida, desistimos da nossa fatia de tempo e tentamos novamente quando a tarefa é reprogramada ou executamos um bloqueio de rotação . Um bloqueio de rotação é um algoritmo como:
Count down from 5000:
i. Execute the test-and-set instruction
ii. If the mutex is clear, we have acquired it in the previous instruction
so we can exit the loop
iii. When we get to zero, give up our time slice.
Quando terminamos de executar nosso código protegido (conhecido como seção crítica ), apenas definimos o valor mutex como zero ou o que significa 'claro'. Se várias tarefas estiverem tentando adquirir o mutex, a próxima tarefa agendada após o lançamento do mutex terá acesso ao recurso. Normalmente, você usaria mutexes para controlar um recurso sincronizado no qual o acesso exclusivo é necessário apenas por períodos muito curtos, normalmente para fazer uma atualização em uma estrutura de dados compartilhada.
Um semáforo é uma estrutura de dados sincronizada (normalmente usando um mutex) que possui uma contagem e alguns wrappers de chamada do sistema que interagem com o planejador com um pouco mais de profundidade do que as bibliotecas mutex. Os semáforos são incrementados e decrementados e usados para bloquear tarefas até que outra coisa esteja pronta. Consulte Problema do produtor / consumidor para obter um exemplo simples disso. Os semáforos são inicializados com algum valor - um semáforo binário é apenas um caso especial em que o semáforo é inicializado como 1. A postagem em um semáforo tem o efeito de ativar um processo de espera.
Um algoritmo básico de semáforo se parece com:
(somewhere in the program startup)
Initialise the semaphore to its start-up value.
Acquiring a semaphore
i. (synchronised) Attempt to decrement the semaphore value
ii. If the value would be less than zero, put the task on the tail of the list of tasks waiting on the semaphore and give up the time slice.
Posting a semaphore
i. (synchronised) Increment the semaphore value
ii. If the value is greater or equal to the amount requested in the post at the front of the queue, take that task off the queue and make it runnable.
iii. Repeat (ii) for all tasks until the posted value is exhausted or there are no more tasks waiting.
No caso de um semáforo binário, a principal diferença prática entre os dois é a natureza dos serviços do sistema em torno da estrutura de dados real.
EDIT: Como evan apontou com razão, os spinlocks desaceleram uma máquina de processador único. Você usaria apenas um spinlock em uma caixa com vários processadores, porque em um único processador o processo que contém o mutex nunca o redefinirá enquanto outra tarefa estiver em execução. Spinlocks são úteis apenas em arquiteturas com vários processadores.