From: williamkempf_at_[hidden]
Date: 2001-03-17 11:56:09
--- In boost_at_y..., williamkempf_at_h... wrote:
> --- In boost_at_y..., <boost_at_y...> 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 : williamkempf_at_h...
> > Description : Boost.Threads draft library submission
> >
> > You can access this file at the URL
> >
> > http://groups.yahoo.com/group/boost/files/threads/threads.zip
> >
> > To learn more about file sharing for your group, please visit
> >
> > http://help.yahoo.com/help/us/groups/files
This file has been updated once again. Incorporated are fixes for
all issues addressed so far (I hope). Also incorporated was stronger
error checking when calling the Win32 API. The pthreads
implementation has not been done in this regard because it is still
not fully working correctly in the first place. I'm still hoping
someone volunteers to help with this, though if I find the time I'll
try and at least diagnose the race condition this weekend.
I've also added a detail namespace in thread.hpp that includes some
common functions needed by the examples and test programs. These
include thread creation, joining on all created threads and
sleeping. These are in the detail namespace because they will be
replaced by more appropriate interfaces in Phase 2 and are not meant
for general use in Phase 1. As such they are poorly implemented and
have some major design holes, but can be safely used by the examples
and tests provided at this time. So, unless a bug is found that
prevents use for the specific examples given, these details should
not be evaluated at this time.
Also added were two new examples. One example is "starvephil" and
illustrates thread starvation caused by condition variables, taken
directly from Communicating Sequential Processes with Java. The
other is "tennis", an example provided by Alexander that I believe
was meant to illustrate the problems found with the ACE
implementation of condition variables, which both Boost.Threads and
pthread-win32 were based on. The problem is, I can not get this
example to produce any "spurious wakeups" with the current
Boost.Threads implementation, let alone stolen signals or deadlock as
Alexander claims can occur. When implementing the Boost.Threads
condition type for Win32 I did discover a race condition in the ACE
implementation which I fixed (and sent a report to Doug Schmidt, but
he's not reachable at the moment to comment on my findings). Maybe
this race condition is what causes the problems addressed by
Alexander and the fix I applied means that the Boost.Threads
implementation is yet another algorithm that will fix the problems.
Or maybe I'm mistaken about the tennis example being an example meant
to illustrate the problems. I don't know at this point and I am
trying to converse with Alexander to diagnose any possible issues
here.
Bill Kempf