[boost] Re: Upcoming ISO/IEC <thread>... and <pthread.h> -> <cthread> transition ;-)

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-06-03 04:57:02

"William E. Kempf" wrote:
[...]
> >> > >> 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.
> >> >
> >> > Absolutely agreed.  I've said all along that Boost.Threads has to be
> >> very aware of what POSIX says.  We can not deviate in any way from
> >> POSIX that will result in conflicts between the threading systems.
> >
> > Bill, Boost.Threads shall end up in standard <thread> header. But there
> > should also be a <cthread> standard header (it should penetrate ISO C as
> >  well; in the form of either <pthread.h> or <cthread.h> header). Now, in
> >  the past, I was thinking of <thread> as "just" an object layer on top
> > of  <cthread> stuff. That was wrong. <cthread> should be fully
> > implementable  using stuff from <thread>. I mean things along the lines
> > of:
> 
> I see no reason for C++ to include a <cthread>, unless it's there for
> compatibility with a C <thread.h>.  

The compatibility issue here is not <thread.h> but rather <pthread.h>.

>                                    IOW, POSIX should address the C
> standard first, not the other way around.  (And not all of POSIX is
> necessarily appropriate, either, as the impact to non-POSIX platforms can
> be quite extensive and you are likely to find opposition from those
> members.)

I'd love to hear something from them. MS-folks, are you here? Y'know,
I guess that NOW, given Microsoft's recent acquisition of "The UNIX 
license" from The SCO (aka "hey-IBM-give-me-a-billion") Group, they 
will have NO problems whatsoever merging win32 and Interix/POSIX sub
systems... http://google.com/groups?selm=3DE4FF8C.FA94CDAC%40web.de

[...typedef std::aligned_storage<std::mutex> pthread_mutex_t;...]

I've recently found&corrected a typo in that snippet. Here's what
I wrote recently: (I hope it's relevant to this discussion as well)

:David Schwartz wrote:
:> 
:> "Wil Evers" <bouncer_at_dev.null> wrote in message
:> news:3ed83fe8$0$2232$e4fe514c_at_dreader6.news.xs4all.nl...
:> 
:> > Not sure I agree.  Assuming no special 'compiler magic' is used, and the
:> > definitions of pthread_mutex_t and PTHREAD_MUTEX_INITIALIZER are shared
:> > between C and C++, then pthread_mutex_t must be a POD and
:> > PTHREAD_MUTEX_INITIALIZER must be a constant expression, 
:
:Yeah. http://google.com/groups?selm=3ED1E663.B9C89A4F%40web.de
:
:"typedef std::aligned_storage<std::mutex> pthread_mutex_t;"
:
:This is meant to be a properly aligned POD; e.g. POD-union with 
:a character array [or whatever] meant to be const-initialized by 
:the <cthread>'s PTHREAD_MUTEX_INITIALIZER. BTW, I've made a typo:
:
:"extern "C" int pthread_mutex_destroy(pthread_mutex_t * mutex_storage) 
:        throw() {
:   // destructor with implicit throw()-nothing ES 
:   ~mutex_storage->object();
:   // "may fail" shall be caught in the std::unexpected() handler
:   return 0;
: }"
:
:actually meant to be:
:
: extern "C" int pthread_mutex_destroy(pthread_mutex_t * mutex_storage) 
:        throw() {
:   // destructor with implicit throw()-nothing ES 
:   mutex_storage->object().~mutex();
:   // "may fail" shall be caught in the std::unexpected() handler
:   return 0;
: }
:
:well, but...
:
:>                                                            so the C++ rules
:> > for dynamic initialization do not apply here.
:
:...see below. ;-)
:
:> 
:>     You are implicitly assuming that the pthreads implementation must
:> strictly conform to the ANSI C standard. Since this is impossible, you
:> should stop assuming it. ;)
:> 
:>     Why can't PTHREAD_MUTEX_INITIALIZER call a function that isn't
:> reentrant? I mean why can't it be:
:> 
:> #define PTHREAD_MUTEX_INITIALIZER get_mutex();
:> #define pthread_mutex_t int;
:> static int next_mutex=0;
:> int get_mutex(void) { return next_mutex++; }
:
:Yeah, something like that; POSIX.1 doesn't really need to care about 
:C++ dynamic init of whatever statics (local or non-local ones). Only
:POSIX.1++ and/or upcoming threaded C++ Std with <cthread> could and
:should sort of "clarify" that. Oder?

Now I'd like to add one more <cthread>'s call:

extern "C++" std::mutex & pthread_mutex(pthread_mutex_t * mutex_storage) 
        throw() {
  return mutex_storage->object();
}

The idea is that you could use <cthread>'s initializers for mutex, 
CV, whatever POD "storage objects" of static storage duration and 
simply "retrieve" a C++ object reference from it for things like 
scoped locking guards and etc.

Well, I'm not sure about 

   std::pthread_mutex_t& std::mutex::c_mutex() throw();

but the *thread object* class should provide

   std::pthread_t std::thread::c_thread() throw();

I believe.

> Give me a valid reason for having a C style interface and I'll certainly
> consider adding it to Boost.Threads and recommending it to the committee.

Just show them this document:

http://std.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1457.pdf

And point "curious folks" to the bits like this:

"....
 Obviously, interface definitions written in the common subset 
 of C and C++ would have the widest potential audience, since 
 they would be readable by compilers for both languages. But 
 the additional abstraction mechanisms of C++, such as classes
 and templates, are useful in writing code at the hardware 
 access layer. They allow the encapsulation of features into 
 classes, providing type safety along with maximum efficiency 
 through the use of templates. 

 Nevertheless, it is an important goal to provide an interface 
 that allows device driver implementers to write code that 
 compiles equally under C and C++ compilers. Therefore, this 
 report specifies two interfaces: one using the common subset 
 of C and C++ and a second using modern C++ constructs. 
 Implementers of the commonsubset style interface might use 
 functions or inline functions, or might decide that function-
 like macros or intrinsic functions better serve their 
 objectives.
 ...."

> But I don't see a need for it myself.
> 
> >> > >> 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.
> >> >
> >> > Agreed, but that's the case today when mixing languages.  There are
> >> a lot of areas which are left unspecified, even when the languages
> >> being mixed are C and C++.
> >
> > C and C++ WILL merge, sooner or later. The separation of C and C++
> > languages is/was the stupidest thing C++ authors ever did (or allowed
> > to happen). Well, just look what's going on with respect to GCC/G++
> > (adding exceptions and C-destructors IS kinda "merging", I believe).
> 
> Strong words (you did the shouting), with no indication this is so from
> any of the people who would dictate this.  Or did I miss something?  

Well, try <http://www.research.att.com/~bs/papers.html>, to begin with.

regards,
alexander.