Re: Thread library and Win32

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 
thread
> library, I'm not sure if they've been covered in previous posts 
before.
> 
> 1) In the various lock implementations, casting HANDLE to unsigned 
long
> 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 
out
> of TLS slots in NT4, and Win9x OS's, perhaps implementing it with a 
data
> 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 
for
> 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 
critical
> section with a spin count instead of a real mutex will give you 
better
> performance in general, but especially on multi-processor systems.
> InitializeCriticalSectionAndSpinCount is only unavailable in Win95, 
and
> 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 
decrements
> 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