From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-15 18:10:25
--- In boost_at_[hidden], <boost_at_[hidden]> wrote:
> This email message is a notification to let you know that
> a file has been uploaded to the Files area of the boost
> File : /threads/threads.zip
> Uploaded by : sirwillard_at_m...
> Description : Win32 test implementation
> You can access this file at the URL
> To learn more about eGroups file sharing, please visit
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
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)
The implementation I have is intead conformant with the following
compare_swap(x, y, z);
if (x == z)
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.
P.S. The included README asks for help with timing/performance
issues. If you can contribute to this it would be greatly
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk