Re: thread lib review

From: williamkempf_at_[hidden]
Date: 2001-09-08 10:47:41

--- In boost_at_y..., John Maddock <John_Maddock_at_c...> wrote:
> 
> >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 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).

> >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.

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 
occured, 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.

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

I understand the concern, but I would hope this wouldn't cause 
problems in porting.
 
> >No, recursive mutexes have been specifically coded to work 
> >correctly. :)
> 
> Ah, I see, cunning :-)

Hopefully :).  I've been a tad concerned that this could lead to 
unforseen races or even deadlocks, since POSIX doesn't support this.  
But I honestly can't see how.
 
> >> #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).

Hmm... that's valid.  Didn't look at it in that light.  OK, I'll do 
this.
 
> >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.

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?
  
> >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.

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.

Bill Kempf