[boost] Re: Semaphores?

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2002-05-24 08:43:27

"Victor A. Wagner, Jr." wrote:
> 
> At Thursday 2002/05/23 11:32, you wrote:
> 
> >"William E. Kempf" wrote:
> >[...]
> > > That said, semaphores aren't strictly "missing forever".  I plan to address
> > > this at some point with more research into the pros/cons.
> >
> >Save your time, Bill. Really.
> 
> Any time you want to take a discussion offline 

Nah, I hate "offline". I just love google! ;-)

> I'll be glad to defend semaphores at length.

You are quite welcomed here (in all these threads,
pick one [or more than one] you like -- that's all
your choice, I mean):

http://groups.google.com/groups?threadm=b9c563f9.0205071053.37baf3c2%40posting.google.com
http://groups.google.com/groups?threadm=3mhE8.15629%24bV3.677568%40news0.telusplanet.net
http://groups.google.com/groups?threadm=3CA2375E.E3A1337B%40tesco.net

[...]
> Try writing a semaphore with only those "primatives" in your toolkit.

That's easy... and only ONE CLICK AWAY from you:

http://groups.google.com/groups?selm=3CE0BCD3.EF695748%40web.de
http://groups.google.com/groups?selm=3CEB6073.ACBCFD17%40web.de
http://groups.google.com/groups?selm=3CEB6F09.F5E0C240%40web.de
http://groups.google.com/groups?selm=slrn9e684t.hp.kaz%40cafe.net

< from the preceding [last] link above >

"....
 Do you have even the slightest clue on how condition variables are used
 correctly or are you just guessing based on reading about them in a manual
 page?"

> I trust that Bill _will_ research them.

Nah, reinvent already widely known 'research' (at best), I guess. ;-)

http://groups.google.com/groups?selm=acko81%24hec%243%40glue.ucr.edu

"....
 Monitors and Conditions were introduced in 1974 and refined to their
 more-or-less current form in 1980 (see Lampson and Reddell).  So, as
 of 1987, they were all that novel.  The automobile industry, not known
 for being a hotbed of innovation, picks up on new technology much more
 quickly.

 : and since events and semaphores would have to be provided to take care of
 : those performance issues, 

 Where did "performance issues" come in?  Sempahore-based mutual
 exclusion traditionally involves passive waiting and the attendant
 overhead of context switching.  Most mutexes are spinlocks.  (AFIK,
 events don't provide mutual exclusion.)

 : they perhaps did not want to include yet another kitchen sink. 

 Good idea.  The issue was then which sink to put in the kitchen:

   - the pre-1974 sink (introduced and to some extent rejected by 
     Dijkstra and Brinch-Hansen) composed of semaphores and events.

   - the post-1974 sink (introduced by Hoare, Lampson, Reddell, et al) 
     that offered higher performance and better structured solutions 
     to thread coordination problems.

 By 1987, they had thirteen years of experience and refinement on which
 to base their decisions. 
 ...."

regards,
alexander.

P.S. < Forward Inline >

-------- Original Message --------
Message-ID: <3CEE1FF3.EC3828FE_at_[hidden]>
Date: Fri, 24 May 2002 13:11:47 +0200
From: Alexander Terekhov <terekhov_at_[hidden]>
Reply-To: terekhov_at_[hidden]
Newsgroups: comp.programming.threads
Subject: Re: many semaphores
References: <b9c563f9.0205071053.37baf3c2_at_[hidden]> <3CD8FAB0.E6272694_at_[hidden]> <b9c563f9.0205090507.735ccbd2_at_[hidden]> <3CDBD51B.3B7839F8_at_[hidden]> <3CEB99C5.88A9B69B_at_[hidden]> <3CEBC872.FF262C8C_at_[hidden]> <3CEBDA71.CC4AA9AA_at_[hidden]> <3CED6484.1060904_at_[hidden]>

Daniel Miller wrote:

[...good stuff...]

Daniel, I really need more than 3..10 minutes (or so) it takes 
to {re}build my C++ jobs on damn slow/busy hosts we have here 
(time windows I use for netnews) to comprehend your stuff and 
try to reply to the rest of your points. (I'll probably throw 
it into my WorkPad organizer and/or ThinkPad and try to find 
some time for it over the weekend). For now, I have just one 
comment/question:

>  Alexander, if you are implementing the idioms for such an API on a particular
> platform, please feel free to implement all of the intraaddress-space ones via
> condition-variables&mutexes alone---although that would be an unfortunate
> limitation of producer-consumer, prohibiting it from pushing messages into a
> FIFO queue from a asynchronous signal/interrupt handler.

Why not use *SIGEV_THREAD*, dedicated thread(s)/sigwait(), 
and/or, perhaps, sort-of try to get rid of "async.signals" 
(interrupts) altogether?!?! (async-"cancel"-safe regions
[for async.exception] SHOULD STAY INTACT, however!!! ;-))

regards,
alexander.