Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #889 > unrolled thread

POSIX threads hard to implement in Windows (was: C is fixed or not ?)

Back to article view | Back to comp.unix.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  POSIX threads hard to implement in Windows (was: C is fixed or not ?) Noob <root@127.0.0.1> - 2011-07-07 15:17 +0200
    Re: POSIX threads hard to implement in Windows William Ahern <william@wilbur.25thandClement.com> - 2011-07-07 11:21 -0700
      Re: POSIX threads hard to implement in Windows Ian Collins <ian-news@hotmail.com> - 2011-07-08 08:07 +1200
        Re: POSIX threads hard to implement in Windows Robert Wessel <robertwessel2@yahoo.com> - 2011-07-07 16:01 -0500
          Re: POSIX threads hard to implement in Windows "MikeP" <mp011011@some.org> - 2011-07-07 21:12 -0500
            Re: POSIX threads hard to implement in Windows Robert Wessel <robertwessel2@yahoo.com> - 2011-07-07 23:33 -0500
              Re: POSIX threads hard to implement in Windows "MikeP" <mp011011@some.org> - 2011-07-07 23:49 -0500
            Re: POSIX threads hard to implement in Windows BGB <cr88192@hotmail.com> - 2011-08-03 07:32 -0700
        Re: POSIX threads hard to implement in Windows William Ahern <william@wilbur.25thandClement.com> - 2011-07-07 15:06 -0700
      Re: POSIX threads hard to implement in Windows lawrence.jones@siemens.com - 2011-07-10 16:08 -0400
        Re: POSIX threads hard to implement in Windows William Ahern <william@wilbur.25thandClement.com> - 2011-07-10 16:09 -0700
          Re: POSIX threads hard to implement in Windows James Kuyper <jameskuyper@verizon.net> - 2011-07-11 06:20 -0400
            Re: POSIX threads hard to implement in Windows Ian Collins <ian-news@hotmail.com> - 2011-07-11 22:36 +1200
        Re: POSIX threads hard to implement in Windows scott@slp53.sl.home (Scott Lurndal) - 2011-07-11 16:18 +0000
          Re: POSIX threads hard to implement in Windows Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-07-12 13:30 +0100
    Re: POSIX threads hard to implement in Windows (was: C is fixed or not ?) Joshua Maurice <joshuamaurice@gmail.com> - 2011-07-07 19:01 -0700
    Re: POSIX threads hard to implement in Windows (was: C is fixed or not ?) "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2011-07-14 23:05 +0200

#889 — POSIX threads hard to implement in Windows (was: C is fixed or not ?)

James Kuyper wrote:

> Lawrence Jones wrote:
>
>> Keith Thompson wrote:
>>
>>> I'm not very familiar with this area, but why would just
>>> incorporating POSIX threads (or perhaps a subset of POSIX threads)
>>> into the C standard not have been a good solution?
>>
>> My understanding, from people who know a whole lot more about it than I
>> do, is that POSIX threads cannot be implemented on top of Windows
>> because it presupposes a bunch of POSIX features that Windows doesn't
>> provide, at least in the form that POSIX threads requires.
> 
> Could you ask those people to provide a more detailed explanation of the
> problem? I doubt that a naked assertion will convince Rui Maciel, and
> I'm curious about the reasons myself.

Please note: I've added comp.unix.programmer (for the POSIX aspects)
and comp.programming.threads (for the threading aspect)

We've been discussing the next revision of the C standard (C1X)
http://en.wikipedia.org/wiki/C1X
Specifically, the inclusion of multi-threading support.

Apparently, Dinkumware's library is being considered, and some
are wondering why the committee did not consider adopting the
POSIX API itself, or a subset thereof.

Would enlightened people in either comp.unix.programmer or
comp.programming.threads comment on these aspects?

Regards.

[toc] | [next] | [standalone]

#897 — Re: POSIX threads hard to implement in Windows

In comp.unix.programmer Noob <root@127.0.0.1> wrote:
> James Kuyper wrote:
> > Lawrence Jones wrote:
> >
> >> Keith Thompson wrote:
> >>
> >>> I'm not very familiar with this area, but why would just
> >>> incorporating POSIX threads (or perhaps a subset of POSIX threads)
> >>> into the C standard not have been a good solution?
> >>
> >> My understanding, from people who know a whole lot more about it than I
> >> do, is that POSIX threads cannot be implemented on top of Windows
> >> because it presupposes a bunch of POSIX features that Windows doesn't
> >> provide, at least in the form that POSIX threads requires.
> > 
> > Could you ask those people to provide a more detailed explanation of the
> > problem? I doubt that a naked assertion will convince Rui Maciel, and
> > I'm curious about the reasons myself.

POSIX threads can be implemented quite comprehensively on Windows:

	http://sourceware.org/pthreads-win32/conformance.html

But anyone who has used POSIX threads and Windows' native API quickly learns
that they're quite different approaches. The biggest difference that I'm
aware of is that Windows' mutexes cannot be statically initialized.
pthreads-win32 handles this with a global Windows' CriticalSection in
pthread_mutex_lock(). AFAIK, the C1x proposal doesn't allow statically
initialized objects, presumably so the interface can be implemented atop
Windows' API without such ugliness.

[toc] | [prev] | [next] | [standalone]

#898 — Re: POSIX threads hard to implement in Windows

On 07/ 8/11 06:21 AM, William Ahern wrote:
> In comp.unix.programmer Noob<root@127.0.0.1>  wrote:
>> James Kuyper wrote:
>>> Lawrence Jones wrote:
>>>
>>>> Keith Thompson wrote:
>>>>
>>>>> I'm not very familiar with this area, but why would just
>>>>> incorporating POSIX threads (or perhaps a subset of POSIX threads)
>>>>> into the C standard not have been a good solution?
>>>>
>>>> My understanding, from people who know a whole lot more about it than I
>>>> do, is that POSIX threads cannot be implemented on top of Windows
>>>> because it presupposes a bunch of POSIX features that Windows doesn't
>>>> provide, at least in the form that POSIX threads requires.
>>>
>>> Could you ask those people to provide a more detailed explanation of the
>>> problem? I doubt that a naked assertion will convince Rui Maciel, and
>>> I'm curious about the reasons myself.
>
> POSIX threads can be implemented quite comprehensively on Windows:
>
> 	http://sourceware.org/pthreads-win32/conformance.html
>
> But anyone who has used POSIX threads and Windows' native API quickly learns
> that they're quite different approaches. The biggest difference that I'm
> aware of is that Windows' mutexes cannot be statically initialized.
> pthreads-win32 handles this with a global Windows' CriticalSection in
> pthread_mutex_lock(). AFAIK, the C1x proposal doesn't allow statically
> initialized objects, presumably so the interface can be implemented atop
> Windows' API without such ugliness.

Does the windows API support process shared mutexes?  The C1x proposal 
doesn't include them probably because the process model is beyond the C 
standard.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#899 — Re: POSIX threads hard to implement in Windows

On Fri, 08 Jul 2011 08:07:30 +1200, Ian Collins <ian-news@hotmail.com>
wrote:

>On 07/ 8/11 06:21 AM, William Ahern wrote:
>> In comp.unix.programmer Noob<root@127.0.0.1>  wrote:
>>> James Kuyper wrote:
>>>> Lawrence Jones wrote:
>>>>
>>>>> Keith Thompson wrote:
>>>>>
>>>>>> I'm not very familiar with this area, but why would just
>>>>>> incorporating POSIX threads (or perhaps a subset of POSIX threads)
>>>>>> into the C standard not have been a good solution?
>>>>>
>>>>> My understanding, from people who know a whole lot more about it than I
>>>>> do, is that POSIX threads cannot be implemented on top of Windows
>>>>> because it presupposes a bunch of POSIX features that Windows doesn't
>>>>> provide, at least in the form that POSIX threads requires.
>>>>
>>>> Could you ask those people to provide a more detailed explanation of the
>>>> problem? I doubt that a naked assertion will convince Rui Maciel, and
>>>> I'm curious about the reasons myself.
>>
>> POSIX threads can be implemented quite comprehensively on Windows:
>>
>> 	http://sourceware.org/pthreads-win32/conformance.html
>>
>> But anyone who has used POSIX threads and Windows' native API quickly learns
>> that they're quite different approaches. The biggest difference that I'm
>> aware of is that Windows' mutexes cannot be statically initialized.
>> pthreads-win32 handles this with a global Windows' CriticalSection in
>> pthread_mutex_lock(). AFAIK, the C1x proposal doesn't allow statically
>> initialized objects, presumably so the interface can be implemented atop
>> Windows' API without such ugliness.
>
>Does the windows API support process shared mutexes?  The C1x proposal 
>doesn't include them probably because the process model is beyond the C 
>standard.


Sure.  Most of the synchronization objects in Windows are system wide.
Access is controlled by the security attributes specified when the
object is created.  There are some local synchronization object, most
notably Critical Sections, which cannot be shared across processes
(the advantage being that their much lighter weight).

[toc] | [prev] | [next] | [standalone]

#906 — Re: POSIX threads hard to implement in Windows

Robert Wessel wrote:
> On Fri, 08 Jul 2011 08:07:30 +1200, Ian Collins <ian-news@hotmail.com>
> wrote:

>> Does the windows API support process shared mutexes?  The C1x
>> proposal doesn't include them probably because the process model is
>> beyond the C standard.
>
>
> Sure.  Most of the synchronization objects in Windows are system wide.

CAN be. If you name them, THEN they can be used amongst processes. 
Unnamed synch objects are intra-process. Whether having unnamed synch 
objects makes them lighter-weight (higher performance) in usage, I don't 
know. Simple enough to profile though.

> Access is controlled by the security attributes specified when the
> object is created.  There are some local synchronization object, most
> notably Critical Sections, which cannot be shared across processes
> (the advantage being that their much lighter weight). 

[toc] | [prev] | [next] | [standalone]

#908 — Re: POSIX threads hard to implement in Windows

On Thu, 7 Jul 2011 21:12:33 -0500, "MikeP" <mp011011@some.org> wrote:

>Robert Wessel wrote:
>> On Fri, 08 Jul 2011 08:07:30 +1200, Ian Collins <ian-news@hotmail.com>
>> wrote:
>
>>> Does the windows API support process shared mutexes?  The C1x
>>> proposal doesn't include them probably because the process model is
>>> beyond the C standard.
>>
>>
>> Sure.  Most of the synchronization objects in Windows are system wide.
>
>CAN be. If you name them, THEN they can be used amongst processes. 
>Unnamed synch objects are intra-process. Whether having unnamed synch 
>objects makes them lighter-weight (higher performance) in usage, I don't 
>know. Simple enough to profile though.


Not true.  Unnamed objects can be shared with child processes under
the correct circumstances.  Alternatively, and more generally, you can
use DuplicateHandle on an unnamed object and create a (new) handle to
that object for another process to use.

[toc] | [prev] | [next] | [standalone]

#909 — Re: POSIX threads hard to implement in Windows

Robert Wessel wrote:
> On Thu, 7 Jul 2011 21:12:33 -0500, "MikeP" <mp011011@some.org> wrote:
>
>> Robert Wessel wrote:
>>> On Fri, 08 Jul 2011 08:07:30 +1200, Ian Collins
>>> <ian-news@hotmail.com> wrote:
>>
>>>> Does the windows API support process shared mutexes?  The C1x
>>>> proposal doesn't include them probably because the process model is
>>>> beyond the C standard.
>>>
>>>
>>> Sure.  Most of the synchronization objects in Windows are system
>>> wide.
>>
>> CAN be. If you name them, THEN they can be used amongst processes.
>> Unnamed synch objects are intra-process. Whether having unnamed synch
>> objects makes them lighter-weight (higher performance) in usage, I
>> don't know. Simple enough to profile though.
>
>
> Not true.  Unnamed objects can be shared with child processes under
> the correct circumstances.

OK. Then I should have wrote: "Unnamed synch objects are GENERALLY 
intra-process" (or some such). (I should have not included additional 
thoughts and stopped at the first carriage return perhaps).

> Alternatively, and more generally, you can
> use DuplicateHandle on an unnamed object and create a (new) handle to
> that object for another process to use.

Sounds like a roundabout way of doing the same thing as naming an object 
though.

Anyway, my point was that they are not NECESSARILY system-wide, and your 
statement implied the opposite. You maybe should have said something 
like: "Most of the synchronization objects in Windows CAN BE system 
wide". (I would have used "inter-process" some way instead of "system 
wide"). 

[toc] | [prev] | [next] | [standalone]

#1053 — Re: POSIX threads hard to implement in Windows

On 7/7/2011 7:12 PM, MikeP wrote:
> Robert Wessel wrote:
>> On Fri, 08 Jul 2011 08:07:30 +1200, Ian Collins<ian-news@hotmail.com>
>> wrote:
>
>>> Does the windows API support process shared mutexes?  The C1x
>>> proposal doesn't include them probably because the process model is
>>> beyond the C standard.
>>
>>
>> Sure.  Most of the synchronization objects in Windows are system wide.
>
> CAN be. If you name them, THEN they can be used amongst processes.
> Unnamed synch objects are intra-process. Whether having unnamed synch
> objects makes them lighter-weight (higher performance) in usage, I don't
> know. Simple enough to profile though.
>

these mutexes are very expensive, almost absurdly slow. a lock/unlock 
cycle takes around 1-2us, which is far longer than most operations one 
may reasonably want to lock (on a reasonably modern computer, this is 
around 3000 to 6000 clock cycles).

"Critical Sections" are a bit faster, and so are preferable to the 
generic mutex objects (but, much faster than dead slow is still not 
necessarily fast).


much faster IME was to implement a spinlock-with-sleeep operation (using 
"InterlockedExchange", ...), which can generally handle 
locking/unlocking in the low ns range (more around 5ns or so).

the above fast mutexes make a lot more sense when ones' goal is 
something like:
lock mutex;
add entry to cross-thread linked list (such as a message queue);
unlock mutex.

or: the corresponding action to remove something from a linked-list.


rather than... whatever the hell MS intends their mutexes for...

[toc] | [prev] | [next] | [standalone]

#900 — Re: POSIX threads hard to implement in Windows

In comp.unix.programmer Ian Collins <ian-news@hotmail.com> wrote:
> On 07/ 8/11 06:21 AM, William Ahern wrote:
<snip>
> > But anyone who has used POSIX threads and Windows' native API quickly learns
> > that they're quite different approaches. The biggest difference that I'm
> > aware of is that Windows' mutexes cannot be statically initialized.
> > pthreads-win32 handles this with a global Windows' CriticalSection in
> > pthread_mutex_lock(). AFAIK, the C1x proposal doesn't allow statically
> > initialized objects, presumably so the interface can be implemented atop
> > Windows' API without such ugliness.
>
> Does the windows API support process shared mutexes?  The C1x proposal 
> doesn't include them probably because the process model is beyond the C 
> standard.

Yes, according to MSDN:

	Multiple processes can have handles of the same mutex object,
	enabling use of the object for interprocess synchronization. The
	following object-sharing mechanisms are available:

	o A child process created by the CreateProcess function can inherit
	  a handle to a mutex object if the lpMutexAttributes parameter of
	  CreateMutex enabled inheritance. This mechanism works for both
	  named and unnamed mutexes.

	o A process can specify the handle to a mutex object in a call to
	  the DuplicateHandle function to create a duplicate handle that can
	  be used by another process. This mechanism works for both named
	  and unnamed mutexes.

	o A process can specify a named mutex in a call to the OpenMutex or
	  CreateMutex function to retrieve a handle to the mutex object.

	Use the CloseHandle function to close the handle. The system closes
	the handle automatically when the process terminates. The mutex
	object is destroyed when its last handle has been closed.

	-- http://msdn.microsoft.com/en-us/library/ms682411%28v=VS.85%29.aspx

[toc] | [prev] | [next] | [standalone]

#927 — Re: POSIX threads hard to implement in Windows

William Ahern <william@wilbur.25thandclement.com> wrote:
> 
> POSIX threads can be implemented quite comprehensively on Windows:
> 
>         http://sourceware.org/pthreads-win32/conformance.html

Then why is there a long list of unimplemented functions?  Certainly
there are *parts* of pthreads that can be implemented on Windows, but
that's not the same thing as implementing the whole thing.
-- 
Larry Jones

Kicking dust is the only part of this game we really like. -- Calvin

[toc] | [prev] | [next] | [standalone]

#929 — Re: POSIX threads hard to implement in Windows

In comp.unix.programmer lawrence.jones@siemens.com wrote:
> William Ahern <william@wilbur.25thandclement.com> wrote:
> > 
> > POSIX threads can be implemented quite comprehensively on Windows:
> > 
> >         http://sourceware.org/pthreads-win32/conformance.html

> Then why is there a long list of unimplemented functions?  Certainly
> there are *parts* of pthreads that can be implemented on Windows, but
> that's not the same thing as implementing the whole thing.

The list isn't that long. What distinguishes those interfaces is that they
can't be implemented on top of, e.g., the stdio implementation. The original
question, as I understood it, was whether the general architecture of
Windows was a reasonable fit for a POSIX threads implementation. Most of the
library can be implemented without unwarranted chumminess with the
underlying implementation, and the remaining pieces--with signals being the
biggest question mark--would appear to require only minimal cooperation by
the vendor.

Not that I believe C1x should adopt pthreads, mind you. Also, the proposal
was qualified--it suggested adopting a _subset_ of pthreads.

[toc] | [prev] | [next] | [standalone]

#931 — Re: POSIX threads hard to implement in Windows

On 07/10/2011 07:09 PM, William Ahern wrote:
> In comp.unix.programmer lawrence.jones@siemens.com wrote:
>> William Ahern <william@wilbur.25thandclement.com> wrote:
>>>
>>> POSIX threads can be implemented quite comprehensively on Windows:
>>>
>>>         http://sourceware.org/pthreads-win32/conformance.html
> 
>> Then why is there a long list of unimplemented functions?  Certainly
>> there are *parts* of pthreads that can be implemented on Windows, but
>> that's not the same thing as implementing the whole thing.
> 
> The list isn't that long. What distinguishes those interfaces is that they
> can't be implemented on top of, e.g., the stdio implementation. The original
> question, as I understood it, was whether the general architecture of
> Windows was a reasonable fit for a POSIX threads implementation. Most of the
> library can be implemented without unwarranted chumminess with the
> underlying implementation, and the remaining pieces--with signals being the
> biggest question mark--would appear to require only minimal cooperation by
> the vendor.
> 
> Not that I believe C1x should adopt pthreads, mind you. Also, the proposal
> was qualified--it suggested adopting a _subset_ of pthreads.

There are two proposals that I'm aware of, neither of which can be
accurately described as a "subset of pthreads". The official proposal is
for changes to the language and a set of new library functions that
could be implemented as thin wrappers for pthreads functions, but are
sufficiently generic in their definitions that they could alternatively
be implemented as thin wrappers for other threading systems.

The second proposal has not been officially made, but has been suggested
in a number of forms in this forum. That proposal is that the entire
pthreads specification from POSIX should be inserted, by reference, into
the C standard. While not explicitly stated, the implications have been
that it would need little or no additional wording would be needed,
beyond the statement that it has been so incorporated.

The list of pthreads features which have not been implemented in Windows
is an argument in favor of the official proposal, over the unofficial
one. In the unlikely event that the second proposal were accepted, a
conforming implementation of C running under Windows would be required
to implement all of the items on that list. How difficult would that be?
If Microsoft has not even attempted to implement them, I imagine it
would be pretty difficult.

The fact that even those features which are available, are available
only in the POSIX Subsystem of Windows, and not for native Windows
programs, is another such argument. If I understand it correctly, the
official proposal defines a system that could be made available even for
native Windows programs.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#932 — Re: POSIX threads hard to implement in Windows

On 07/11/11 10:20 PM, James Kuyper wrote:
>
> The list of pthreads features which have not been implemented in Windows
> is an argument in favor of the official proposal, over the unofficial
> one. In the unlikely event that the second proposal were accepted, a
> conforming implementation of C running under Windows would be required
> to implement all of the items on that list. How difficult would that be?
> If Microsoft has not even attempted to implement them, I imagine it
> would be pretty difficult.
>
> The fact that even those features which are available, are available
> only in the POSIX Subsystem of Windows, and not for native Windows
> programs, is another such argument. If I understand it correctly, the
> official proposal defines a system that could be made available even for
> native Windows programs.

Maybe those features will be implemented when they get around to 
implementing C99?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#935 — Re: POSIX threads hard to implement in Windows

lawrence.jones@siemens.com writes:
>William Ahern <william@wilbur.25thandclement.com> wrote:
>> 
>> POSIX threads can be implemented quite comprehensively on Windows:
>> 
>>         http://sourceware.org/pthreads-win32/conformance.html
>
>Then why is there a long list of unimplemented functions?  Certainly
>there are *parts* of pthreads that can be implemented on Windows, but
>that's not the same thing as implementing the whole thing.

A quick examination of the list of functions concludes that they
fit into one of the following categories:

  - Not applicable to windows (pthread_atfork, getpwnam_r, et. al.)
  - An optional POSIX feature (robust mutexes)
  - stdio & C Library extensions
  - signals

It looks like cancellation points are the most difficult feature of
pthreads to implement on windows - this reference notes that the
application must explictly code the cancellation points into the
application using non-standard API's.

scott

[toc] | [prev] | [next] | [standalone]

#937 — Re: POSIX threads hard to implement in Windows

Scott Lurndal wrote:

> lawrence.jones@siemens.com writes:
>>William Ahern <william@wilbur.25thandclement.com> wrote:
>>> 
>>> POSIX threads can be implemented quite comprehensively on Windows:
>>> 
>>>         http://sourceware.org/pthreads-win32/conformance.html
>>
>>Then why is there a long list of unimplemented functions?  Certainly
>>there are *parts* of pthreads that can be implemented on Windows, but
>>that's not the same thing as implementing the whole thing.
>
> A quick examination of the list of functions concludes that they
> fit into one of the following categories:
>
>   - Not applicable to windows (pthread_atfork, getpwnam_r, et. al.)
>   - An optional POSIX feature (robust mutexes)
>   - stdio & C Library extensions
>   - signals

Robust mutexes are not optional in POSIX.

They were a new addition in the current (2008) standard; it looks
like the pthreads-win32 implementation still targets the old 2001
standard.  (The web page says _POSIX_THREADS etc. are defined as
200112L.)  However, since robust mutexes are mentioned in the
conformance status perhaps an update to POSIX 2008 is planned.

-- 
Geoff Clare <netnews@gclare.org.uk>

[toc] | [prev] | [next] | [standalone]

#905

On Jul 7, 6:17 am, Noob <r...@127.0.0.1> wrote:
> James Kuyper wrote:
> > Lawrence Jones wrote:
>
> >> Keith Thompson wrote:
>
> >>> I'm not very familiar with this area, but why would just
> >>> incorporating POSIX threads (or perhaps a subset of POSIX threads)
> >>> into the C standard not have been a good solution?
>
> >> My understanding, from people who know a whole lot more about it than I
> >> do, is that POSIX threads cannot be implemented on top of Windows
> >> because it presupposes a bunch of POSIX features that Windows doesn't
> >> provide, at least in the form that POSIX threads requires.
>
> > Could you ask those people to provide a more detailed explanation of the
> > problem? I doubt that a naked assertion will convince Rui Maciel, and
> > I'm curious about the reasons myself.
>
> Please note: I've added comp.unix.programmer (for the POSIX aspects)
> and comp.programming.threads (for the threading aspect)
>
> We've been discussing the next revision of the C standard (C1X)http://en.wikipedia.org/wiki/C1X
> Specifically, the inclusion of multi-threading support.
>
> Apparently, Dinkumware's library is being considered, and some
> are wondering why the committee did not consider adopting the
> POSIX API itself, or a subset thereof.
>
> Would enlightened people in either comp.unix.programmer or
> comp.programming.threads comment on these aspects?

Why didn't they adopt the POSIX API itself? I suspect a couple of
reasons.

First compatibility with C++0x. Of course, that begs the question of
why didn't the C, C++, and POSIX committees when working together
decide to adopt the POSIX pthreads standard?

Second, the POSIX pthreads standard is underspecified, and incomplete,
and slightly buggy. It's buggy in the informal simple specification of
try_lock. It's incomplete because it's missing all of the non
sequentially consistent atomics, eg: fences and such. And if you're
going to specify fences portably, you need a rigorously defined memory
model, which C++0x and C1x will give you.

In spirit, C1x and C++0x are compatible in spirit with POSIX pthreads.
They will give you the same primitives with different names, more or
less.

Finally, I suppose you could ask why not fix and extend POSIX
pthreads? They may have been political, see: Windows. Perhaps they
thought they had a better chance to drag Windows kicking and screaming
if they made a new standard?

[toc] | [prev] | [next] | [standalone]

#946

On Thu, 7 Jul 2011, Noob wrote:

> James Kuyper wrote:
>
>> Lawrence Jones wrote:
>>
>>> Keith Thompson wrote:
>>>
>>>> I'm not very familiar with this area, but why would just
>>>> incorporating POSIX threads (or perhaps a subset of POSIX threads)
>>>> into the C standard not have been a good solution?
>>>
>>> My understanding, from people who know a whole lot more about it than I
>>> do, is that POSIX threads cannot be implemented on top of Windows
>>> because it presupposes a bunch of POSIX features that Windows doesn't
>>> provide, at least in the form that POSIX threads requires.
>>
>> Could you ask those people to provide a more detailed explanation of the
>> problem? I doubt that a naked assertion will convince Rui Maciel, and
>> I'm curious about the reasons myself.
>
> Please note: I've added comp.unix.programmer (for the POSIX aspects)
> and comp.programming.threads (for the threading aspect)
>
> We've been discussing the next revision of the C standard (C1X)
> http://en.wikipedia.org/wiki/C1X
> Specifically, the inclusion of multi-threading support.
>
> Apparently, Dinkumware's library is being considered, and some
> are wondering why the committee did not consider adopting the
> POSIX API itself, or a subset thereof.
>
> Would enlightened people in either comp.unix.programmer or
> comp.programming.threads comment on these aspects?

Perhaps relevant, from 2010-Jul:

"harmonization(?) of threading interfaces between POSIX/SUS and C1X"

- POSIX discussion:
http://comments.gmane.org/gmane.comp.standards.posix.austin.general/2640

- comp.std.c discussion:
http://groups.google.com/group/comp.std.c/browse_frm/thread/61d6ab42db75f19a/fe2b250e2864d136

lacos

[toc] | [prev] | [standalone]

Back to top | Article view | comp.unix.programmer

csiph-web