> '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 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: > Joe Seigh 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" @sources.redhat.com on 12/20/2001 12:06:26 PM Please respond to Sent by: pthreads-win32-owner@sources.redhat.com To: 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 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