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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-06-03 05:57:43

Alexander Terekhov said:
> "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>.

Which is a POSIX header, not a C or C++ header.  I'm not going to suggest
that the C++ language standard be made compatible with POSIX, nor do I
think you'd be able to convince the committee of this if *you* were to
suggest it.

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

I wasn't specifically meaning MS.  After all, the Windows platform is
already at least partially POSIX.  There are other, non-POSIX platforms,
however.

But I'm sure MS would have issues with adopting all of POSIX if you were
to suggest it.  There are certain areas which are incompatible, such as
path naming, which would be problematic at best to be switched over to a
POSIX compatible form.  And this one even rears its ugly head in pthreads
(indirectly) where shared memory is created with path names.

> [...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)

I'm lost.  I never referenced what you are talking about here.  I'll have
to spend some time reading all of this thread (including your links) to
get back on track.  A better job of quoting would save both of us some
time here.

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

I follow what's said here, but can't figure out what you want me to pay
attention to.

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

You've got some interesting ideas for merging POSIX and C++.  But, I'm
sorry, I just can't get on board here.  Providing a POSIX C++ binding
would require actual language changes, would probably force non-POSIX
platforms to make some significant changes which could be prohibitive
(though the pthreads library alone doesn't have too much specified that
would obviously cause such problems), and I think would be a very hard
sell.

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

Quoted out of context.  In context, this is about hardware I/O support. 
Completely different subject matter, and I'm not at all sure that what's
said above applies to *this* context.

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

I'm aware of most of these papers already.  They don't indicate any plans
to merge C and C++, that I can see.  He discusses syntax compatibility,
not binary compatibility.  I may be wrong, but I don't think either
commitee wants to specify an ABI, and with out doing that, I'm not sure
how you can mandate compatibility between compilers, much less languages.

-- 
William E. Kempf