Re: thread lib review

From: williamkempf_at_[hidden]
Date: 2001-09-09 19:55:14

--- In boost_at_y..., John Maddock <John_Maddock_at_c...> wrote:
> 
> >I wasn't aware that POSIX had a counting semaphore?  Regardless, 
the 
> >limit isn't truly infinity is it?  Infinity certainly 
> >wouldn't "simplify" the implementation AFAICS.  I also don't see 
how 
> >a fixed max size would simplify things over a user specified max 
size 
> >(within limits).
> 
> What I'm suggesting is the rest of the lib follows the POSIX 
standard quite
> closely - except for semaphore.

Coincidence and the happy circumstance that POSIX is very well 
thought out.  However, I'm not sure I agree with POSIX in this 
particular case.  Counting semaphores are useful for limiting access 
to a resource to a specified number of threads.  With out being able 
to set a maximum value it's very possible to accidently increment the 
semaphore value more times then you should have, resulting in an 
error whereby too many threads are allowed access.  Defining the 
maximum shouldn't be a terribly burdensome requirement on the 
implementation, and it definately illiminates some sources of error.

> >When debugging you want the trap to occur as close to the error as 
> >possible, which is what asserts are good at.  With an exception 
the 
> >debugger will trap several levels down from where the error 
actually 
> >occurred, possibly even further down than a debugger allows you to 
> >traverse back up the stack with.  Also, many (most?) debuggers 
allow 
> >you to step over the assertion, which would allow you to debug 
your 
> >exception trapping code.  To my mind asserts are for debugging and 
> >exceptions are for error handling.
> 
> OK, but does that mean that operator new should assert rather than 
throw?
> These are both resource acquisition errors.

Only in theory.  On Win32 there can be multiple reasons for the 
failure, so it's useful to trap as close to the error as possible 
during debug.
 
> >Well, I don't know BeOS, but if it supports mutexes then you can 
> >emulate a condition, much as we did for Win32.  The emulation will 
be 
> >much more efficient if BeOS has a counting semaphore, though.  
Does 
> >it?
> 
> It has a counting semaphore and nothing else (no mutexes etc), 
there is
> also no user-defined upper limit to the semaphore (like POSIX), and 
it's
> not FIFO as far as know (does that matter?).

No more so then it will matter for a mutex built on top of this.  In 
other words, FIFO ordering can eliminate a lot of non-determinism and 
resultant race conditions, but this is true for all synchronization 
mechanisms.  If you can build a mutex on BeOS with just this 
semaphore then you can build a condition as well.
 
> >Even the POSIX specific stuff isn't always 100% portable and/or 
> >detectable.  For example, pthread_yield() does not appear to be 
> >universally available, nor is there a defined macro that indicates 
> >it's presence or not.  Though I could be wrong.  I'm not a POSIX 
> >programmer and have relied on research and input from others.
> 
> It's got no macro, because it doesn't exist as far as POSIX is 
concerned:
> POSIX used sched_yield() for this, and it's predicated on:

Sorry, I typed that from memory.  You're quite right, I meant 
sched_yield().
 
> defined(_POSIX_PRIORITY_SCHEDULING) && (_POSIX_PRIORITY_SCHEDULING 
> 0)

I've seen several "portable" threading libraries that seem unaware of 
this.  Like I said, I'm not a POSIX expert.  If someone can replace 
the hard coded definitions with POSIX sanctioned ones, even if they 
aren't 100% portable because of flawed implementations, then I'm all 
for them doing so.  I just don't have the knowledge to do this.

Bill Kempf