>> and the NPTL code in glibc *seems* to perform a memory barrier only on
>> sem_post().
>
> Wouldn't that seem quite natural ? Semas provide one-way communication.
> It's the sem_post() that means there is an event to be seen by some
> other thread. So it has to make sure that any data related to it is
> visible to the receiver. The receiver taking the event (returning
> from sem_wait()), or checking for it (calling sem_wait()), is not
> meant to be an event for the other side. You need a second sema if
> events have to go both ways.
from my understanding, sem_post() implies a write barrier (stores have been
executed before sem_post()) and sem_wait() a read barrier (loads have to be
executed after sem_wait()).
tim
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Jul 12 04:15:02 2011
This archive was generated by hypermail 2.1.8 : Tue Jul 12 2011 - 04:15:02 EEST