This is the mail archive of the pthreads-win32@sources.redhat.com mailing list for the pthreas-win32 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> implementation

Stick to PTHREADS. You might want to have a look at

http://www.terekhov.de/mythread.c

"my_thread_t" is meant to be inherited or
aggregated by the C++ thread objects.

regards,
alexander.

----

Alexander Terekhov <terekhov@web.de> on 12/07/2001 10:02:22 AM

To:   msdn@microsoft.com
cc:
Subject:  RE: CST49063444ID - Fwd: Re: Metered sections



G'Day,

I am just curious whether someone from
"appropriate Microsoft group" really spend
a minute or two for review of

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndllpro/html/msdn_metrsect.asp


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
msdn, IMHO.

BTW, another article on MSDN:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndllpro/html/msdn_locktest.asp


is buggy too (has similar kind of synchronization
errors)...

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
review..

regards,
alexander.

msdn@microsoft.com schrieb am 16.11.01:
> Hello Alexander,
>

>
Thanks for writing to MSDN.
>

> We have forwarded your comments onto the appropriate Microsoft group
for
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,
feel
free to write us back.
> Thanks again for your continued support and have a nice day!
>

>
Arvin
>
MSDN
> http://msdn.microsoft.com
>

> --- Original Message ---
> From:    terekhov@web.de
> To:      msdn@microsoft.com
> Sent:    Fri Nov 16 02:50:28 PST 2001
> Subject: Fwd: Re: Metered sections
>

> G'Day,
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndllpro/html/msdn_metrsect.asp

>
"A Quick and Versatile Synchronization Object
>
>
>
> Send feedback to MSDN"
>
here it is:
>
Ursprüngliche Nachricht:
> From: terekhov@web.de (Alexander Terekhov)
> Newsgroups: comp.programming.threads
> Subject: Re: Metered sections
> References: <2oDI7.33628$XM4.1499@afrodite.telenet-ops.be>
<3BF39BE2.A4D36C97@genuity.com>
> NNTP-Posting-Host: 129.42.208.148
> Message-ID: <c29b5e33.0111160150.527b215a@posting.google.com>
>
Joe Seigh <jseigh@genuity.com> wrote in message
news:<3BF39BE2.A4D36C97@genuity.com>...
> > a0a wrote:
> > >
> > > Hi everyone,
> > >
> > > I've read about metered sections on the MSDN pages and it seems
it's
a fast
> > > and crossprocess alternative to critical sections and semaphores.
We're
> > > still deciding on which way to go, support native threads of some
kind in
> > > 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
the
right
> > > noises to make an educated choice. If anyone has any advice I
would
be
> > > delighted to read it.  Our target platform is clearly W2k and our
system
> > > will be completely written using the MSVC++ 6.0 compiler,
furtheron
we put
> > > very strong emphasis on speed stability and responsiveness, in
that
> > > particular order.
> > >
> > > I'll assume that everybody who uses pthreads in c++ has written
wrapper
> > > classes written up for them, so my question is also if someone
has
them
> > > available for download somewhere.  We will probably rework them
anyway, so
> > > we don't care about the setup or the format much.
> > >
> >
> > The write up is here.
> >
> >
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndllpro/html/msdn_metrsect.asp

> >
> > 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.
>
regards,
> alexander.


"Ignace Saenen" <ignace.saenen@pandora.be>@sources.redhat.com on 12/20/2001
12:06:26 PM

Please respond to <ignace.saenen@mailandnews.com>

Sent by:  pthreads-win32-owner@sources.redhat.com


To:   <pthreads-win32@sources.redhat.com>
cc:
Subject:  new to pthreads





Hi everyone,

I'm new to this list (and new to pthreads) and I see I dropped in a bit
late
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
section.

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 implementation, that has a few
synchronisation possibilities and, most importantly that it has a run
method
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
non-portable?

Cheers,
Ignace

(sorry Thomas for mailing directly by accident)


-----Original Message-----
From: pthreads-win32-owner@sources.redhat.com
[mailto:pthreads-win32-owner@sources.redhat.com]On Behalf Of Thomas
Pfaff
Sent: Thursday, December 20, 2001 10:25 AM
To: Pthreads-Win32@Sources.Redhat.Com
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
> destructors,
> 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
> C++
> 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()
> should
> 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
> wouldn't
> depend on pthread_exit() or pthread_cancel() allowing destructors to run
> to be
> portable though.  Since the primary purpose of this library is to
> enhance
> 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
using it.


> 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
> the
> "nasty hacks" being removed and a clean C interface version of the
> library
> being provided only.

Try the GC stuff and report bugs.

>
> My two cents,
> Dave
>
>
> --- Ross Johnson <rpj@ise.canberra.edu.au> 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(
__CLEANUP_C )

#if defined(_MSC_VER)
#define __CLEANUP_SEH
#elif defined(__cplusplus)
#define __CLEANUP_CXX
#else
#define __CLEANUP_C
#endif

#endif

These defaults have been added to be backward compatible and it is time to
remove them.


> > 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
> >
>

Regards,
Thomas






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]