Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at