>> 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@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
