Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-10-24 15:18:28

--- In boost_at_y..., "Anson Tsao" <ansont_at_m...> wrote:
> I have a few observations about the Win32 implementation of the
> library, I'm not sure if they've been covered in previous posts
> 1) In the various lock implementations, casting HANDLE to unsigned
> is not portable to IA64, HANDLE is the same size as pointers. Should
> probably cast to void* instead.

We were waiting on clarification as to how MS was going to handle
this in the C RTL. I'll be making this modification before the next
release since we have enough information to go on now.

> 2) WaitForSingleObject return values that are not WAIT_OBJECT_0 are
> asserted in a number of places. They are runtime conditions that can
> return WAIT_ABANDONED, should probably throw an exception instead.

Possibly. AFAIK, however, the MS platform is the only one that has
the concept of abandoned mutexes, so I hesitate to add an exception
type for this platform specific case. I'll give it much greater
thought now that it's raised by someone else.

> 3) Thread specific pointer implementation, it's pretty easy to run
> of TLS slots in NT4, and Win9x OS's, perhaps implementing it with a
> structure using only one TLS slot is safer.

This one has been discussed and is likely to happen even for POSIX
implementations (they suffer the same thing here). My original
concern was in adding a possible error to the initial set operation
since dynamic memory allocations would be used. I'm reconsidering
this stance, however, since I've been informed that POSIX already has
this quality any way. (Someone else has also claimed to have a
solution that would not require dynamic allocation, so the
implementation may change once the actual solution is provided to me.)
> Extending the thread object interface:
> 1) Creating the thread with attributes: stack size, priority are
> portable between Win32 and POSIX, perhaps an optional opaque type
> platform specific attributes

Stack size is portable to Win32 and POSIX, yes. I'm a little
concerned about other implementations, however, so I'm going to do
some more research on this before the final decision. As for
priority, it's not a simple thing to make portable. The levels of
priority are not going to be universally identical. Some thought has
to be put into deciding how to represent the priority level in a
portable manner.

We need some good discussions about how to handle the other platform
specific attributes. Many of them can be handled by free functions,
but some must be set at creation time which makes things at least
slightly more difficult. The opaque parameter solution is an easy
one, I'm only concerned that it may not be the best solution in a C++
design. I'd love to hear discussion of other options from others on
the list.
> Other thoughts:
> 1) Since the mutex class is only for process local use, using
> section with a spin count instead of a real mutex will give you
> performance in general, but especially on multi-processor systems.
> InitializeCriticalSectionAndSpinCount is only unavailable in Win95,
> NT4 pre SP3 systems.

In general I agree. This one was discussed on the list and the
rationale for the choice was given with links to the research paper
that lead to the (overly?) cautious choice. I strongly expect to
change the implementation in this area, but I want to finish my
research in this area before I do. I can try and address this in the
very near future.

> 2) Portable thread traits class with atomic increments and
> functions might be very useful

That is a huge can of worms. During development Boost.Threads had an
atomic_t class that basically provided the same thing here. There
are very large issues with both portability and safety, though, so it
was removed in the final submission. The issue with portability
mostly has to do with the difficulty of writing a portable library
for this that would cover the vast number of platforms that
Boost.Threads will be used on. This won't be as much of an issue for
library implementers if the C++ committee standardized such a
concept. However, the safety remains a serious concern. A lot of
things that users tend to use atomic integer operations for wind up
being a hairball on some platforms because of memory synchronization
issues. To make the concept useful in a portable manner you'd have
to also include a memory barrier, and then there'd be so few
programmers that could understand how to use the two together in a
safe manner that I'm not sure anyone is served by having these
concepts provided in a "portable" manner.

Something that is universally wanted, however, is a ref_count type of
concept which we could do in a portable manner.

Bill Kempf

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