From: John Maddock (John_Maddock_at_[hidden])
Date: 2001-09-08 06:41:10
>It's not truly a MS thing. There's a lot of documentation out there
>that describes both binary semaphores (the classic) and counting
>semaphores (what Boost.Threads has), and a lot of this was published
>before Win32 existed. There are a lot of benefits to a counting
>semaphore and native implementations should be doable on any platform
>(though you're correct that I've emulated them for POSIX today).
I'm not suggesting that you restrict us to a binary semaphore - I'm
suggesting that the upper limit of the count is infinity - that's what
POSIX does for example, and it greatly simplifies implementation.
>I'm holding off on such changes to see precisely how MS themselves
>address this in 64 bit.
>The assert allows for debugging while the throw insures an error is
>raised in release. Can't really do with out either one. I will
>however look to make sure there's not something wrong.
It just seems wrong to me that debug code asserts and release code throws -
especially for what is runtime error. How am I supposed to debug my
exception trapping code - if it's only available in release mode? OK there
are workarounds, but this behaviour looks likely to cause surprises to me.
>It is correct, and it's not caused any problems so far. Can the
>concern be made more real?
No, I'm concerned about porting to non-Win32, non-POSIX threads. I guess
we'll have to wait and see :-)
>No, recursive mutexes have been specifically coded to work
Ah, I see, cunning :-)
>> # error
>> It makes it easier to catch a mis-configured set of headers.
>But won't be correct for the final "full" implementation, since not
>all platforms will support all clock types.
The #error would be present if the platform supports *no* clock types -
it's there to catch mis-configuration in other words - and if no clock
types are configured the code won't actually run will it? (or at least the
test program didn't when I tried it).
>With boost/thread/config.hpp this problem isn't possible.
>BOOST_HAS_THREADS is conditionally defined dependent on those other
>macros as well as detection of whether or not threading support
>is "on" by the compiler. I'm not sure how to work this out with the
>new config system. I'll have to get some help integrating this
>portion if accepted.
OK, the only real issue I have is that some parts of the thread lib are
easier to port than others - the mutexes would be trivial to port to BeOS
for example, but I'm not too sure about condition variables - I was
thinking ahead to what would happen if only part of the lib had been ported
to a new platform.
>Some don't have feature tests, unfortunately. Getting the config
>stuff correct is going to take some doing.
Yes, I spotted that some were not POSIX standard interfaces - I would guess
that these are GLIBC specific? If so they would fit into the new config
system quite easily.
- John Maddock
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk