This is the mail archive of the
mailing list for the pthreas-win32 project.
Re: new to pthreads
- From: "Alexander Terekhov" <TEREKHOV at de dot ibm dot com>
- To: pthreads-win32 at sources dot redhat dot com
- Date: Thu, 20 Dec 2001 12:52:23 +0100
- Subject: Re: new to pthreads
> 'metered sections', which exist in windows allowing to
> sync over process and thread boundaries and behaving much
> like a critical section.
see attached messages below (no response from Microsoft yet).
> Ultimately what I would like to write/have is a C++ TThread
> class based on a IThread interface that is "portable" in that
> it can be implemented by a pthread implementation or native
Stick to PTHREADS. You might want to have a look at
"my_thread_t" is meant to be inherited or
aggregated by the C++ thread objects.
Alexander Terekhov <email@example.com> on 12/07/2001 10:02:22 AM
Subject: RE: CST49063444ID - Fwd: Re: Metered sections
I am just curious whether someone from
"appropriate Microsoft group" really spend
a minute or two for review of
article and the problems i've briefly outlined
in my posting to c.p.t which i've forwarded to
your support organization ??
The buggy synchronization presented in the
article (sleep(0) looping aside) is really,
really not worth publishing on such site as
BTW, another article on MSDN:
is buggy too (has similar kind of synchronization
Care to review/respond?
I can provide additional details to someone from
"appropriate Microsoft group" if he/she will not
be able to idetify syncronization bugs during
firstname.lastname@example.org schrieb am 16.11.01:
> Hello Alexander,
Thanks for writing to MSDN.
> We have forwarded your comments onto the appropriate Microsoft group
review and response. By taking the time to write, you are helping us
provide the best possible products and services.
If there are other concerns with regards to our products and services,
free to write us back.
> Thanks again for your continued support and have a nice day!
> --- Original Message ---
> From: email@example.com
> To: firstname.lastname@example.org
> Sent: Fri Nov 16 02:50:28 PST 2001
> Subject: Fwd: Re: Metered sections
"A Quick and Versatile Synchronization Object
> Send feedback to MSDN"
here it is:
> From: email@example.com (Alexander Terekhov)
> Newsgroups: comp.programming.threads
> Subject: Re: Metered sections
> References: <2oDI7.33628$XM4.firstname.lastname@example.org>
> NNTP-Posting-Host: 18.104.22.168
> Message-ID: <email@example.com>
Joe Seigh <firstname.lastname@example.org> wrote in message
> > a0a wrote:
> > >
> > > Hi everyone,
> > >
> > > I've read about metered sections on the MSDN pages and it seems
> > > and crossprocess alternative to critical sections and semaphores.
> > > still deciding on which way to go, support native threads of some
> > > W2k, or write C++ wrapper classes on top of pthreads.
Go with POSIX threads.
> > Right now we don't
> > > have real experience with either of both, so we're looking for
> > > noises to make an educated choice. If anyone has any advice I
> > > delighted to read it. Our target platform is clearly W2k and our
> > > will be completely written using the MSVC++ 6.0 compiler,
> > > very strong emphasis on speed stability and responsiveness, in
> > > particular order.
> > >
> > > I'll assume that everybody who uses pthreads in c++ has written
> > > classes written up for them, so my question is also if someone
> > > available for download somewhere. We will probably rework them
> > > we don't care about the setup or the format much.
> > >
> > The write up is here.
> > From what I could tell from a brief examination,
> > it's sample code, not part of windows.
> > It uses shared memory and diy spinlocks.
> > I wouldn't characterize it as a general purpose
> > synchronization primitive.
I would characterize it as a *buggy* implementation
> of a counting semaphore with rather useless MAX count
> using auto-reset event and awful "while:InterlockedExchange;
> Sleep(0)" thing. It is yet another good example showing
> why events are "bad"/error-prone, however.
"Ignace Saenen" <email@example.com>@sources.redhat.com on 12/20/2001
Please respond to <firstname.lastname@example.org>
Sent by: email@example.com
Subject: new to pthreads
I'm new to this list (and new to pthreads) and I see I dropped in a bit
into this discussion, but with the discussion is still hot I learned that
there are some difficulties involving the _exit and _clean methods with c++
destructor implementations. I downloaded pthreads win this week as I am
interested in a STABLE (specification wise and debug wise) and if possible
also portable thread library for a windows application.
According to DECthread specs
(http://www.openvms.compaq.com:8000/72final/6493/6101pro_031.html), the (or
is it "it's") pthread interface is interoperable with windows thread
functions, is this also the case with MFC code enabled? Compared to the
windows specification, pthread-win code looks pretty complex and domestic,
and seems to lack 'metered sections', which exist in windows allowing to
sync over process and thread boundaries and behaving much like a critical
Ultimately what I would like to write/have is a C++ TThread class based on
IThread interface that is "portable" in that it can be implemented by a
pthread implementation or native implementation, that has a few
synchronisation possibilities and, most importantly that it has a run
that I can override. As I see it now, I am able to use pthreads up to a
certain extent for this, keeping my TThread class portable, but the
destructor is problematic when stack unwinding occurs in the threadfunction
on termination conditions like _exit/_cancel, unless the code is
(sorry Thomas for mailing directly by accident)
[mailto:firstname.lastname@example.org]On Behalf Of Thomas
Sent: Thursday, December 20, 2001 10:25 AM
Subject: Re: pthreads VCE: problem with destructor
On Wed, 19 Dec 2001, reentrant wrote:
> Due to the nature of the beast just as the responsibility lies with the
> programmer to design the program to "cleanly" (including running
> ad nauseum) exit when exit() is called, it should also be the
> responsibility of
> the programmer to design a thread to cleanly exit with pthread_exit() or
> pthread_cancel() are called. Just as exit() should not be called in a
> program if dtors are desired to run neither should pthread_exit() from a
> thread. IMHO.
> I would imagine that exit() was chosen not to be modified to account for
> running C++ destructors for about the same reasons that pthread_exit()
> not account for running C++ destructors. Dtors not being called in
> these cases
> is and should be expected behavior.
> Regardless as Mr. Bossom so well has already stated: I certainly
> depend on pthread_exit() or pthread_cancel() allowing destructors to run
> to be
> portable though. Since the primary purpose of this library is to
> portability of programs using pthreads, counting on pthread_exit() or
> pthread_cancel() to work in a non-portable way seems self-defeating.
This is exactly the reason why i have created the setjmp/longjmp version.
There may be bugs in it but i think they could be discovered if more would
> While attempting to allow dtors to be run upon a pthread_exit() or
> pthread_cancel() is certainly a noble goal, it's beyond the scope of the
> pthread library. It's the programmer's responsibility IMHO.
> So, as I hope is obvious by this point :), I am completely in support of
> "nasty hacks" being removed and a clean C interface version of the
> being provided only.
Try the GC stuff and report bugs.
> My two cents,
> --- Ross Johnson <email@example.com> wrote:
> > I sense a rising and ruthless desire to deal with the problem of
> > the exception-based versions of the library. It would certainly
> > be a lot easier if they weren't there, and there are some
> > hacks in pthread.h supporting them that really are nasty.
> > So ... what to do about them?
> > I will firstly put John's warning in the README file
> > and the README.NONPORTABLE file, and on the Web page.
> > Secondly, there is a standard C version of the library courtesy
> > of Thomas Pfaff's contributions. It uses setjmp/longjmp.
> > Does this need to be built differently to work with C++
> > applications (assuming they are written as John suggests they
> > should be)?
No. The only thing you need is to define __CLEANUP_C to avoid the default
handling in pthread.h.
* define defaults for cleanup code
#if !defined( __CLEANUP_SEH ) && !defined( __CLEANUP_CXX ) && !defined(
These defaults have been added to be backward compatible and it is time to
> > I can try putting it through the VCE run of the
> > test suite as soon as I reinstall my corrupted Windows 98 machine.
> > Thirdly, if possible, consider phasing out all but the VC and GC
> > versions of the library (currently the only standard C versions).
> > That is, phase out the VCE, VSE, and GCE versions.
> > Does anyone wan't to jump up and shout - NO!!
> > Ross