Re: New file uploaded to boost

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-15 18:10:25

--- In boost_at_[hidden], <boost_at_[hidden]> wrote:
> 
> Hello,
> 
> This email message is a notification to let you know that
> a file has been uploaded to the Files area of the boost 
> group.
> 
>   File        : /threads/threads.zip 
>   Uploaded by : sirwillard_at_m... 
>   Description : Win32 test implementation  
> 
> You can access this file at the URL
> 
> http://www.egroups.com/files/boost/threads/threads%2Ezip 
> 
> To learn more about eGroups file sharing, please visit
> 
> http://www.egroups.com/help/files.html
> 
> 
> Regards,
> 
> sirwillard_at_m...

Several things have been changed here.

First, I've included a makefile for MinGW.  I'm not a g++ expert, so 
anyone familiar with this compiler could look at this makefile and 
make suggestions on better command line options to use.  The 
resulting executable currently includes debug info (I'm not sure how 
to supply parameters to GNU make to allow the makefile to produce 
either debug or release builds, and the debug builds are currently 
more important).

The header files are now all 100% portable.  The Windows header files 
needed by the code is now hidden within the source files.  This is 
important for several reasons, chief among them being to allow ANSI 
compilation of code that uses the thread headers (the Windows headers 
use some MS extensions).

I've eliminated all warnings in gcc using -Wall.

The atomic_t has been reworked as per the notes from the metting in 
Toronto (see below).

A preliminary implementation of a thread class has been added.

Things worthy of discussion:

I still don't know if I'm sold on the atomic_t type being used by 
stand alone functions instead of using member functions.  I'd like to 
hear why this was decided on at the meeting.  Also, the notes 
indicate the following about compare_swap:

   compare_swap(x, z, y);
      if (x != z)
         swap(x, y);

The implementation I have is intead conformant with the following 
pseudo code:

   compare_swap(x, y, z);
      if (x == z)
         swap(x, y);

The order of the parameters is the least of the differences (I'm not 
sure why the notes indicate the reversal of the last two parameters, 
especially when alphabetically it's indicated that logically they are 
swapped).  If there's a compelling reason for this I'm more than 
willing to reverse them.  No, the more important difference is in the 
comparison.  The Win32 InterlockedCompareExchange compares for 
equality, not inequality, and I think that's the way it should be.  
Is this a typo in the meeting notes or a simple mistake or is it 
generally assumed that it should be a test for inequality?

The thread implementation in this code is VERY preliminary.  It 
contains what I think is the minimum requirements for functionality.  
However, the interface and some semantics may need to change 
drastically for portability and safety reasons.  It's included for 
two reasons:  to eliminate the inclusion of the Windows headers by 
the test harnesses (with the timings being an obvious exception) and 
to be the basis for the start of discussion on this Concept.  I don't 
have time to open the discussion up on this one right now, but 
enterprising individuals can look at the code and start the 
discussion off themselves.

Bill Kempf

P.S.  The included README asks for help with timing/performance 
issues.  If you can contribute to this it would be greatly 
appreciated.