[boost] Re: thread lib review

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.

OK.

>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 
>correctly. :)

Ah, I see, cunning :-)

>> #else
>> #  error
>> #endif
>> 
>> 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
http://ourworld.compuserve.com/homepages/john_maddock/