Re: [boost] [thread] semaphore

Subject: Re: [boost] [thread] semaphore
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2013-09-20 14:02:43

El 19/09/2013 18:14, Tim Blechmann escribió:
> sorry, but i strongly disagree: i think that boost is the place for
> high-performance code, that power users can rely on. i don't know how
> many `power users' have to maintain abstractions for low-level
> primitives. regarding semaphores, can you please mention one operating
> system, that does not support them natively?

I agree. But we should also try to guess what memory order guarantees 
should a boost/standard semaphore offer. Interprocess currently uses 
full-fence operations on spin-semaphores (just like in other primivites, 
like mutexes, which is too strong for mutexes and maybe for semaphores).

To be used as a binary semaphore, I guess wait()/post() could be just 
acquire/release. But I don't know if this applies to counting semaphores 
(and specially get_value(). I can read an old thread on this:

https://groups.google.com/forum/#!topic/comp.programming.threads/HpUwUUjgLK8

with Alexander Therekov stating acquire/release is not enough. A 
mutex/condvar emulation can offer strong guarantees than 
acquire/release? Maybe POSIX sem_getvalue might be the hard part to 
maintain only acquire/release fences.

Should we have different "optimized" versions of a semaphore depending 
on the memory order guarantees? I'd love to hear what memory-model 
experts think about this.

Best,

Ion

PD: POSIX has sem_getvalue which has no equivalent in Win32 API, but if 
needed, NtQuerySemaphore could be useful in NT-based windows systems.