[boost] Re: semaphores?

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-06-03 09:26:37

Dan'l Miller wrote:
> 
> Date: Sat, 25 May 2002 15:27:26 -0700
> From: Jive Dadson <djones_at_[hidden]>
> [...snip...]
> > I want to emphasize that I am asking for my own education, not to stir
> > up trouble.  With that in mind, I suggest that "these proceedings are
> > closed."  If you would be kind enough to do me a favor and direct my
> > attention to some article that has examples of the semaphore's dark
> > side, please email me at jdadson_at_ix.netcom.com.
> 
>   I would also like to receive such an "education". Anyone responding 
> to the above-quoted request, either please respond via a posting in 
> reply to this thread or please send me private email at optikos_at_[hidden]
> 
>   (Studying abroad, so to speak, in a such a foreign anti-semaphore 
> land should prove to be somehow enlightening to me.)

http://groups.google.com/groups?threadm=3CEB6073.ACBCFD17%40web.de
http://groups.google.com/groups?threadm=3CEAD916.CDB79911%40web.de
http://groups.google.com/groups?threadm=3CEE1FF3.EC3828FE%40web.de

"[...good stuff...]" -> my sort-of belated 'quick' reply:

: 3) POSIX spinlock iff 6 is absent in design;
:   POSIX mutex or POSIX semaphore iff POSIX spinlock absent from OS and 6 is absent 
:   from design;
:   POSIX rwlock iff 6 is present in design

POSIX mutex is MUCH BETTER (*more suitable* here) than POSIX semaphore

:   4) POSIX spinlock iff 7 is absent in design;
:     POSIX mutex or POSIX semaphore iff POSIX spinlock absent from OS and 6 is absent 
:     from design;
:     POSIX rwlock iff 7 is present in design

POSIX mutex is MUCH BETTER (*more suitable* here) than POSIX semaphore

:   9) POSIX semaphore encapsulated within a producer-consumer class:
:      to eliminate leaks, only push signals/increments semaphore
:      to eliminate leaks, only pop waits/decrements semaphore

No, *PROCESS_PRIVATE* POSIX mutexes and condition variables for whatever 
queues you need/like

:   10) POSIX semaphore encapsulated within a producer-consumer class
:      to eliminate leaks, only push signals/increments semaphore
:      to eliminate leaks, only pop waits/decrements semaphore

No, *PROCESS_SHARED* POSIX mutexes and condition variables for whatever 
queues you need/like

:   11) POSIX datalink-layer or network-layer protocols coupled with a semaphore 
:      encapsulated within a producer-consumer class on the destination processor
:      to eliminate leaks, only push signals/increments semaphore
:      to eliminate leaks, only pop waits/decrements semaphore

No, *PROCESS_SHARED* POSIX mutexes and condition variables for whatever 
queues you need/like

:   12) POSIX semaphore encapsulated within a pool-dispenser class:
:      to eliminate leaks, only guard ctor signals/increments semaphore
:      to eliminate leaks, only guard ctor waits/decrements semaphore

No, *PROCESS_PRIVATE* POSIX mutexes and condition variables for whatever 
pool-dispensers you need/like

:   13) POSIX semaphore encapsulated within a pool-dispenser class:
:      to eliminate leaks, only guard ctor signals/increments semaphore
:      to eliminate leaks, only guard ctor waits/decrements semaphore

No, *PROCESS_SHARED* POSIX mutexes and condition variables for whatever 
pool-dispensers you need/like

:   14) datalink-layer or network-layer protocols to a single semaphore (located 
:      on a single processor) encapsulated within a pool-dispenser class:
:      to eliminate leaks, only guard ctor signals/increments semaphore
:      to eliminate leaks, only guard ctor waits/decrements semaphore

No, *PROCESS_SHARED* POSIX mutexes and condition variables for whatever 
pool-dispenser you need/like

regards,
alexander.

P.S. < !!!isolation/IPC and 'unlock/post'-async-signal-safety aside!!! >
     "....
      In between the append and signal operation, the queue has N+1 items,
      but the semaphore's value is out of date at N. 

      A semaphore has an internal lock which protects incremnts and decrements
      of its internal counter. There is no way to extend that lock to cover
      additional data such as a queue. With a mutex and condition variable,
      the entire queue can be treated as a semaphore based on its *own*
      state!

      So really, the samephore provides only a kludgy solution to synchronization
      problems that are based on simple counting. ...." --Kylheku_at_c.p.t.

      and, perhaps: < very *very* simple example, just an 'illustration' >

      http://groups.google.com/groups?selm=3BA067DC.2527AEF1%40web.de