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
> >that describes both binary semaphores (the classic) and counting
> >semaphores (what Boost.Threads has), and a lot of this was
> >before Win32 existed. There are a lot of benefits to a counting
> >semaphore and native implementations should be doable on any
> >(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
> 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
> >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
> >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
> especially for what is runtime error. How am I supposed to debug my
> exception trapping code - if it's only available in release mode?
> are workarounds, but this behaviour looks likely to cause surprises
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
> 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
> >all platforms will support all clock types.
> The #error would be present if the platform supports *no* clock
> it's there to catch mis-configuration in other words - and if no
> types are configured the code won't actually run will it? (or at
> test program didn't when I tried it).
Hmm... that's valid. Didn't look at it in that light. OK, I'll do
> >With boost/thread/config.hpp this problem isn't possible.
> >BOOST_HAS_THREADS is conditionally defined dependent on those
> >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
> >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
> easier to port than others - the mutexes would be trivial to port
> 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
> 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
> >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
> that these are GLIBC specific? If so they would fit into the new
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk