Re: boost::mutex::scoped_lock conventions

From: Alexander Terekhov (yg-boost-users_at_[hidden])
Date: 2003-05-21 10:03:25

Alexander Terekhov wrote:
> 
> "William E. Kempf" wrote:
> [...]
> > The motivations are backwards here, though.  If the C++ language adopts a
> > threading library, POSIX systems will have a lot of motivation for
> > defining a POSIX C++ binding, or at the very least, making a particular
> > implementation's POSIX binding compatible with the C++ threading.
> 
> How about moving this discussion to c.p.t.?

Well, just in case... <Forward Quoted>

David Butenhof wrote:
> 
> Alexander Terekhov wrote:
> 
> >> > "William E. Kempf" wrote:
> >> The motivations are backwards here, though.  If the C++ language adopts a
> >> threading library, POSIX systems will have a lot of motivation for
> >> defining a POSIX C++ binding, or at the very least, making a particular
> >> implementation's POSIX binding compatible with the C++ threading.
> 
> Right now, the C++ language has, by default and convention, a POSIX binding;
> 1003.1-2001. The C and C++ languages are sufficiently interoperable that
> this presents only a few restrictions on the use by C++ code, around
> exceptions and member functions. OK, so the thread start routine needs to
> be 'extern "C"' -- a minor inconvenience. OK, so there's no portable
> standard on interoperability between POSIX cleanup and C++ exceptions, and
> I'll resist suggesting that only an idiot would fail to make them
> completely compatible and interoperable; but at least most people can be
> educated to realize that they ought to be.
> 
> The big hurdle for a true C++ binding is that the current state of affairs
> is "good enough" for most people, and the political process of developing a
> full native C++ binding would be painful. (Remember, it's not just saying
> that the thread::create method takes a class member at which the thread
> will start... it means reviewing every method and template in the STL to
> determine which have thread safety requirements, and deciding precisely
> what those requirements are and how to meet them. Then there's the matter
> of cancellation points... and so forth.)
> 
> When and if the C++ standard adds true thread support, that will be, by
> default and in practice, the thread binding for C++; whether the underlying
> thread environment is POSIX, Win32, or something else. This is great, as
> long as it doesn't do or say anything stupid, but it still leaves a few
> loopholes because inevitably people will continue to write applications
> that mix languages. Mixing C and C++ has never been a problem; but if the
> thread model in C++ is radically different, it could become a problem.
> Furthermore, there's a missing piece that neither POSIX 1003.1-2001 plus
> ISO C++ 2005 (or whatever), or even 1003.1-2001 plus a hypothetical
> "1003.C++" will necessarily (or even likely) supply -- and that's how the
> two interoperate.
> 
> If C++ or 1003.C++ says that thread::cancel raises an exception, and 1003.1
> says that pthread_cancel() invokes cleanup handlers, does that mean that
> cancelling a thread with pthread_cancel() will trigger catch(...), or even
> destructors? Well, maybe not. This could more easily be solved with a
> 1003.C++, perhaps, since at least the two standards are in a family. Since
> the C++ standard is unlikely to mention POSIX any more than now, it's
> unlikely to provide any guarantees.
> 
> Perhaps that would provide an opportunity for a smaller POSIX project,
> though; a PROFILE that would chink the holes where the two walls meet. In
> effect, specifying a "POSIX platform" supporting both threads and C++ that
> simply says "C++ cancellation is the same as POSIX cancellation", "POSIX
> cleanup handlers are logically and semantically the same as C++ object
> destructors", and "POSIX cancellation is visible as a C++ exception".
> 
> --
> /--------------------[ David.Butenhof_at_[hidden] ]--------------------\
> | Hewlett-Packard Company       Tru64 UNIX & VMS Thread Architect |
> |     My book: http://www.awl.com/cseng/titles/0-201-63392-2/     |
> \----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/

regards,
alexander. < playing "arabic telephone", an electronic one ;-) >

--
"// Possible implementation for <iohw.h>
 #include <hardware>
 using namespace std::hardware;"
             
                        -- 02-0054/N1396