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,
> >limit isn't truly infinity is it? Infinity certainly
> >wouldn't "simplify" the implementation AFAICS. I also don't see
> >a fixed max size would simplify things over a user specified max
> >(within limits).
> What I'm suggesting is the rest of the lib follows the POSIX
> 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
> >debugger will trap several levels down from where the error
> >occurred, possibly even further down than a debugger allows you to
> >traverse back up the stack with. Also, many (most?) debuggers
> >you to step over the assertion, which would allow you to debug
> >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
> 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
> >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
> >much more efficient if BeOS has a counting semaphore, though.
> It has a counting semaphore and nothing else (no mutexes etc),
> also no user-defined upper limit to the semaphore (like POSIX), and
> 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
> POSIX used sched_yield() for this, and it's predicated on:
Sorry, I typed that from memory. You're quite right, I meant
> defined(_POSIX_PRIORITY_SCHEDULING) && (_POSIX_PRIORITY_SCHEDULING
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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk