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

Groups > comp.lang.c > #7823 > unrolled thread

The threading specs in the standard: a new catastrophe

Back to article view | Back to comp.lang.c

Contents

  The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-07 12:33 +0200
    Re: The threading specs in the standard: a new catastrophe Juha Niskanen <juniskan@paju.oulu.fi.nospam> - 2011-07-07 12:46 +0000
    Re: The threading specs in the standard: a new catastrophe Todd Carnes <toddcarnes@gmail.com> - 2011-07-07 13:12 +0000
      Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-07 17:11 +0200
        Re: The threading specs in the standard: a new catastrophe lawrence.jones@siemens.com - 2011-07-08 09:23 -0400
        Re: The threading specs in the standard: a new catastrophe Todd Carnes <toddcarnes@gmail.com> - 2011-07-08 15:20 +0000
    Re: The threading specs in the standard: a new catastrophe "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-07-07 07:36 -0700
      Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-07 17:09 +0200
        Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-07 18:00 +0200
          Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-07 18:20 +0200
    Re: The threading specs in the standard: a new catastrophe Wojtek Lerch <wojtek_l@yahoo.ca> - 2011-07-07 12:31 -0400
      Re: The threading specs in the standard: a new catastrophe Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-07 09:40 -0700
        Re: The threading specs in the standard: a new catastrophe Wojtek Lerch <wojtek_l@yahoo.ca> - 2011-07-07 14:42 -0400
          Re: The threading specs in the standard: a new catastrophe Chad <cdalten@gmail.com> - 2011-07-07 12:03 -0700
            Re: The threading specs in the standard: a new catastrophe Angel <angel+news@spamcop.net> - 2011-07-07 19:27 +0000
              Re: The threading specs in the standard: a new catastrophe Chad <cdalten@gmail.com> - 2011-07-07 12:55 -0700
                Re: The threading specs in the standard: a new catastrophe Angel <angel+news@spamcop.net> - 2011-07-07 20:13 +0000
      Re: The threading specs in the standard: a new catastrophe Ian Collins <ian-news@hotmail.com> - 2011-07-08 09:14 +1200
        Re: The threading specs in the standard: a new catastrophe Wojtek Lerch <wojtek_l@yahoo.ca> - 2011-07-07 23:58 -0400
          Re: The threading specs in the standard: a new catastrophe Ian Collins <ian-news@hotmail.com> - 2011-07-08 16:24 +1200
        Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-08 12:14 +0200
          Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-10 00:02 +0200
            Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-10 14:47 +0200
              Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-11 21:05 +0200
                Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-11 22:50 +0200
                  Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-11 23:56 +0200
                    Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-12 07:50 +0200
                      Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-16 01:14 +0200
                        Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-16 10:08 +0200
                          Re: The threading specs in the standard: a new catastrophe Miles Bader <miles@gnu.org> - 2011-07-18 11:11 +0900
                            Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-18 21:50 +0200
                              Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-19 08:36 +0200
                                Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-21 11:56 +0200
                          Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-22 20:31 +0200
                            Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-22 21:36 +0200
                              Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-23 10:50 +0200
                                Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-23 20:29 +0200
                                  Re: The threading specs in the standard... Alexander Terekhov <terekhov@web.de> - 2011-08-03 15:50 +0200
    Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-07 23:07 +0200
      Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-07 23:32 +0200
        Re: The threading specs in the standard: a new catastrophe jameskuyper <jameskuyper@gmail.com> - 2011-07-07 15:25 -0700
          Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-07 16:12 -0700
            Re: The threading specs in the standard: a new catastrophe James Kuyper <jameskuyper@verizon.net> - 2011-07-07 22:41 -0400
            Re: The threading specs in the standard: a new catastrophe "Chris M. Thomasson" <cristom@charter.net> - 2011-07-08 12:47 -0700
              Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-08 13:11 -0700
                Re: The threading specs in the standard: a new catastrophe "Chris M. Thomasson" <cristom@charter.net> - 2011-07-08 16:56 -0700
                Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-09 23:55 +0200
                  Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-09 18:40 -0700
        Re: The threading specs in the standard: a new catastrophe "MikeP" <mp011011@some.org> - 2011-07-07 23:32 -0500
        Re: The threading specs in the standard: a new catastrophe lawrence.jones@siemens.com - 2011-07-08 10:09 -0400
          Re: The threading specs in the standard: a new catastrophe Shao Miller <sha0.miller@gmail.com> - 2011-07-08 10:31 -0400
    Re: The threading specs in the standard: a new catastrophe Shao Miller <sha0.miller@gmail.com> - 2011-07-08 00:38 -0400
    Re: The threading specs in the standard: a new catastrophe Ian Collins <ian-news@hotmail.com> - 2011-07-08 17:10 +1200
      Re: The threading specs in the standard: a new catastrophe James Kuyper <jameskuyper@verizon.net> - 2011-07-08 07:46 -0400
        Re: The threading specs in the standard: a new catastrophe Ian Collins <ian-news@hotmail.com> - 2011-07-08 23:52 +1200
          Re: The threading specs in the standard: a new catastrophe James Kuyper <jameskuyper@verizon.net> - 2011-07-08 08:23 -0400
            Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-08 14:54 +0200
            Re: The threading specs in the standard: a new catastrophe Ian Collins <ian-news@hotmail.com> - 2011-07-09 08:26 +1200
          Re: The threading specs in the standard: a new catastrophe Seebs <usenet-nospam@seebs.net> - 2011-07-08 14:47 +0000
    Re: The threading specs in the standard: a new catastrophe Juha Niskanen <juniskan@paju.oulu.fi.nospam> - 2011-07-08 07:52 +0000

Page 3 of 3 — ← Prev page 1 2 [3]

#7901

jacob navia wrote:
...
> In general, I am not at all sure of WHY the C standard must decide this.
> Thread libraries are working OK, and POSIX pthreads is widely used.
>
> It would be better that the C standard would scrap all this and add
> a line:
>
> "The threads specifications follows the POSIX standard."
>
> Microsoft has implemented it under windows, and some companies
> have ported it to windows. Support from the C standard would
> be a good thing.

It's extremely unlikely to be that simple; the details of what it
means to follow only a part of the POSIX standard need to be
specified. I don't know anything specific about that part of the POSIX
standard, but I would guess that there's a good chance that it cross-
references other parts of the POSIX standard, either explicitly or
implicitly. If so, for each such cross-reference, the C committee
would have to decide whether to add that other section, too, or to add
words indicating how the meaning of that cross-reference should be
modified in the context of the new C standard. But let's assume all
such issues can be dealt with.

The result of such a change to the C standard would be that if there
is any code which relies only upon the current C standard, and that
portion of the POSIX standard, an implementation of C conforming to
the new C standard will be required to translate that code so that it
works in accordance with POSIX specifications, even if that
implementation is running on a Windows platform.

Now, William Ahern cross-posted a message to every group that this
message is posted to, except comp.std.c, in the thread with the
subject "POSIX threads hard to implement in Windows". In it, he
indicated that one of the biggest ways in which the Windows version of
pthreads differs from true POSIX pthreads is that Windows mutexes
cannot be statically initialized. Therefore, implementers of next
version of C on a Windows platform face a challenge: how to make
statically initialized mutexes work as they are required to by POSIX
(and therefore, also by the new version of C), even though they are
not permitted by the Windows version of pthreads.
I'm not very knowledgeable about this area myself, so it's entirely
possible that I've garbled William Ahern's meaning. Any corrections
that might be needed in order for that paragraph to make sense would
be greatly appreciated.

Since you yourself are a C implementer for Windows platforms, would
you care to describe an implementation strategy for dealing with this
challenge?

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

#7904

On Jul 7, 3:25 pm, jameskuyper <jameskuy...@gmail.com> wrote:
> jacob navia wrote:
>
> ...
>
> > In general, I am not at all sure of WHY the C standard must decide this.
> > Thread libraries are working OK, and POSIX pthreads is widely used.
>
> > It would be better that the C standard would scrap all this and add
> > a line:
>
> > "The threads specifications follows the POSIX standard."
>
> > Microsoft has implemented it under windows, and some companies
> > have ported it to windows. Support from the C standard would
> > be a good thing.
>
> It's extremely unlikely to be that simple; the details of what it
> means to follow only a part of the POSIX standard need to be
> specified. I don't know anything specific about that part of the POSIX
> standard, but I would guess that there's a good chance that it cross-
> references other parts of the POSIX standard, either explicitly or
> implicitly. If so, for each such cross-reference, the C committee
> would have to decide whether to add that other section, too, or to add
> words indicating how the meaning of that cross-reference should be
> modified in the context of the new C standard. But let's assume all
> such issues can be dealt with.
>
> The result of such a change to the C standard would be that if there
> is any code which relies only upon the current C standard, and that
> portion of the POSIX standard, an implementation of C conforming to
> the new C standard will be required to translate that code so that it
> works in accordance with POSIX specifications, even if that
> implementation is running on a Windows platform.
>
> Now, William Ahern cross-posted a message to every group that this
> message is posted to, except comp.std.c, in the thread with the
> subject "POSIX threads hard to implement in Windows". In it, he
> indicated that one of the biggest ways in which the Windows version of
> pthreads differs from true POSIX pthreads is that Windows mutexes
> cannot be statically initialized. Therefore, implementers of next
> version of C on a Windows platform face a challenge: how to make
> statically initialized mutexes work as they are required to by POSIX
> (and therefore, also by the new version of C), even though they are
> not permitted by the Windows version of pthreads.
> I'm not very knowledgeable about this area myself, so it's entirely
> possible that I've garbled William Ahern's meaning. Any corrections
> that might be needed in order for that paragraph to make sense would
> be greatly appreciated.
>
> Since you yourself are a C implementer for Windows platforms, would
> you care to describe an implementation strategy for dealing with this
> challenge?

The simplest mapping of the posix mutex type to windows is the
CRITICAL_SECTION data type.  The only difference between the two is
that a posix mutex may have attributes that allow it to be used to
synchronize between processes via a shared memory segment.  Since
multiple processes and shared memory go beyond the C standard, it
shouldn't need to worry about them.  Those concepts are platform
specific, after all.

Assuming you use a CS as a mutex, then the only nontrivial thing to
have is PTHREAD_MUTEX_INITIALIZER.  Fortunately, recent versions of
Microsoft windows allow static initialization of these via the
definition:
#define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}

However, this isn't the end of the story.  One can do better by using
the low-level thread synchronization primitives that Microsoft uses to
implement locks and condition variables.  Using "keyed events" it is
possible to outperform the standard locking routines Microsoft
provides...

Steven

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

#7918

On 07/07/2011 07:12 PM, sfuerst wrote:
> On Jul 7, 3:25�pm, jameskuyper <jameskuy...@gmail.com> wrote:
>> jacob navia wrote:
...
>>> It would be better that the C standard would scrap all this and add
>>> a line:
>>
>>> "The threads specifications follows the POSIX standard."
...
>> It's extremely unlikely to be that simple; the details of what it
>> means to follow only a part of the POSIX standard need to be
>> specified. I don't know anything specific about that part of the POSIX
>> standard, but I would guess that there's a good chance that it cross-
>> references other parts of the POSIX standard, either explicitly or
>> implicitly. If so, for each such cross-reference, the C committee
>> would have to decide whether to add that other section, too, or to add
>> words indicating how the meaning of that cross-reference should be
>> modified in the context of the new C standard. But let's assume all
>> such issues can be dealt with.
...
>> Now, William Ahern cross-posted a message to every group that this
>> message is posted to, except comp.std.c, in the thread with the
>> subject "POSIX threads hard to implement in Windows". In it, he
>> indicated that one of the biggest ways in which the Windows version of
>> pthreads differs from true POSIX pthreads is that Windows mutexes
>> cannot be statically initialized. Therefore, implementers of next
>> version of C on a Windows platform face a challenge: how to make
>> statically initialized mutexes work as they are required to by POSIX
>> (and therefore, also by the new version of C), even though they are
>> not permitted by the Windows version of pthreads.
>> I'm not very knowledgeable about this area myself, so it's entirely
>> possible that I've garbled William Ahern's meaning. Any corrections
>> that might be needed in order for that paragraph to make sense would
>> be greatly appreciated.
>>
>> Since you yourself are a C implementer for Windows platforms, would
>> you care to describe an implementation strategy for dealing with this
>> challenge?
> 
> The simplest mapping of the posix mutex type to windows is the
> CRITICAL_SECTION data type.  The only difference between the two is
> that a posix mutex may have attributes that allow it to be used to
> synchronize between processes via a shared memory segment.

That's a prime example of the cross-referencing problem I was referring
to: the committee would have to decide either to add a specification for
processes and shared memory, or to add wording beyond what jacob gives
above, modifying whatever it is that the POSIX standard says about such
things within the part that describes pthreads.
-- 
James Kuyper

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

#7999

"sfuerst" <svfuerst@gmail.com> wrote in message 
news:d8d63934-ea1d-4135-a5f2-1fd7b834042a@v12g2000vby.googlegroups.com...

[...]

> Assuming you use a CS as a mutex, then the only nontrivial thing to
> have is PTHREAD_MUTEX_INITIALIZER.  Fortunately, recent versions of
> Microsoft windows allow static initialization of these via the
> definition:
> #define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}

Can you point me to some documentation please?

Thanks.

[...] 

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

#8009

On Jul 8, 12:47 pm, "Chris M. Thomasson" <cris...@charter.net> wrote:
> "sfuerst" <svfue...@gmail.com> wrote in message
>
> news:d8d63934-ea1d-4135-a5f2-1fd7b834042a@v12g2000vby.googlegroups.com...
>
> [...]
>
> > Assuming you use a CS as a mutex, then the only nontrivial thing to
> > have is PTHREAD_MUTEX_INITIALIZER.  Fortunately, recent versions of
> > Microsoft windows allow static initialization of these via the
> > definition:
> > #define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}
>
> Can you point me to some documentation please?
>
> Thanks.
>
> [...]

The CRITICAL_SECTION structure is defined in Winnt.h

Description of what the fields do is described here:
http://msdn.microsoft.com/en-us/magazine/cc164040.aspx
Basically, the above initializes things in the unlocked state, with an
invalid DebugInfo field.  This corresponds to the effects of
InitializeCriticalSection() when it cannot allocate memory.

Older versions of Microsoft Windows raise exceptions instead of using
the "invalid field" trick, so the above will not work for them.

Steven

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

#8015

"sfuerst" <svfuerst@gmail.com> wrote in message 
news:b7a31b8c-bbfb-4b9e-b53c-4be3e94944cc@q15g2000yqk.googlegroups.com...

[...]

> Description of what the fields do is described here:
> http://msdn.microsoft.com/en-us/magazine/cc164040.aspx
> Basically, the above initializes things in the unlocked state, with an
> invalid DebugInfo field.  This corresponds to the effects of
> InitializeCriticalSection() when it cannot allocate memory.

> Older versions of Microsoft Windows raise exceptions instead of using
> the "invalid field" trick, so the above will not work for them.

Thank you. 

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

#8043

sfuerst wrote:
> On Jul 8, 12:47 pm, "Chris M. Thomasson"<cris...@charter.net>  wrote:
>> "sfuerst"<svfue...@gmail.com>  wrote in message
>> news:d8d63934-ea1d-4135-a5f2-1fd7b834042a@v12g2000vby.googlegroups.com...
>> [...]
>>
>>> Assuming you use a CS as a mutex, then the only nontrivial thing to
>>> have is PTHREAD_MUTEX_INITIALIZER.  Fortunately, recent versions of
>>> Microsoft windows allow static initialization of these via the
>>> definition:
>>> #define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}
>>
>> Can you point me to some documentation please?
>
> The CRITICAL_SECTION structure is defined in Winnt.h
>
> Description of what the fields do is described here:
> http://msdn.microsoft.com/en-us/magazine/cc164040.aspx

Note, however, that the article is not an official Microsoft 
documentation, and indeed there's an Editor's Note at the top, which 
says one should not use such tricks in production code.
-- 
Marcin Grzegorczyk

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

#8051

On Jul 9, 2:55 pm, Marcin Grzegorczyk <mgrze...@poczta.onet.pl> wrote:
> sfuerst wrote:
> > On Jul 8, 12:47 pm, "Chris M. Thomasson"<cris...@charter.net>  wrote:
> >> "sfuerst"<svfue...@gmail.com>  wrote in message
> >>news:d8d63934-ea1d-4135-a5f2-1fd7b834042a@v12g2000vby.googlegroups.com...
> >> [...]
>
> >>> Assuming you use a CS as a mutex, then the only nontrivial thing to
> >>> have is PTHREAD_MUTEX_INITIALIZER.  Fortunately, recent versions of
> >>> Microsoft windows allow static initialization of these via the
> >>> definition:
> >>> #define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}
>
> >> Can you point me to some documentation please?
>
> > The CRITICAL_SECTION structure is defined in Winnt.h
>
> > Description of what the fields do is described here:
> >http://msdn.microsoft.com/en-us/magazine/cc164040.aspx
>
> Note, however, that the article is not an official Microsoft
> documentation, and indeed there's an Editor's Note at the top, which
> says one should not use such tricks in production code.
> --
> Marcin Grzegorczyk

Which doesn't prevent Microsoft from using the technique in its own C
library one little bit. ;-)

Steven

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

#7935

jacob navia wrote:

> In general, I am not at all sure of WHY the C standard must decide
> this. Thread libraries are working OK, and POSIX pthreads is widely
> used.
> It would be better that the C standard would scrap all this and add
> a line:
>
> "The threads specifications follows the POSIX standard."

And then C could bow (curtsy?) and exit stage left, never to return again 
to the MS theater. That may even be a better suggestion than dropping ALL 
of the standard libraries. Ugly-like-Unix systems then uniquely have (the 
also ugly) POSIX and Windows will uniquely have Win32. Then the POSIX 
folks could FOCUS on something like a Dot-Not-for-Unix and stop worrying 
so much about minutia.

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

#7969

In comp.std.c jacob navia <jacob@spamsink.net> wrote:
>
> "The threads specifications follows the POSIX standard."
> 
> Microsoft has implemented it under windows, and some companies
> have ported it to windows.

Microsoft has *not*, to my knowledge, implemented pthreads under
Windows. They have included it as part of their "POSIX Subsystem", which
is a POSIX emulation environment much like cygwin.  It's great for
porting POSIX code to a Windows machine, but it's completely useless for
native Windows programs.
-- 
Larry Jones

Oh, what the heck.  I'll do it. -- Calvin

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

#7970

On 7/8/2011 10:09, lawrence.jones@siemens.com wrote:
> In comp.std.c jacob navia<jacob@spamsink.net>  wrote:
>>
>> "The threads specifications follows the POSIX standard."
>>
>> Microsoft has implemented it under windows, and some companies
>> have ported it to windows.
>
> Microsoft has *not*, to my knowledge, implemented pthreads under
> Windows. They have included it as part of their "POSIX Subsystem", which
> is a POSIX emulation environment much like cygwin.  It's great for
> porting POSIX code to a Windows machine, but it's completely useless for
> native Windows programs.

A complication might be using "Windows" instead of "Windows NT" and 
"Windows API".  Yes, they have implemented it for "Windows NT" via the 
POSIX subsystem.  No, they have not implemented it as or via the 
"Windows API" (but another project has).

Nit-pick: Interix isn't suppose to be an "emulation" of anything, to my 
knowledge; it's a peer to the Windows subsystem.  "Much like Cygwin": 
Sure.  A difference: Cygwin lies on top of the Windows subsystem and 
Interix doesn't.

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

#7937

On 7/7/2011 06:33, jacob navia wrote:
> The committee has decided, for reasons unknown to me (there is no
> explanation why is this necessary anywhere) to go on with the flawed
> Dinkum library specs and proclaim that library as the new standard specs
> for the whole language, what will surely please Plauger but leaves the
> rest of us with a pile of errors.
>

Uh oh.

> I posted in this group on June 8th, 2009, a detailed critique of that
> library. Two years later all the original errors are there, together
> with new ones. I will repost again then, the most glaring errors with
> the hope that the committee corrects them before is too late and stops
> this whole idea.
>

But ought a future C Standard to cover threads _somehow_?  As I 
mentioned before, the sequencing model is really striking in C1X.  It 
has "before" and "after" (and un- and indeterminately, etc.)...  Thread 
discussion would seem to cover "simultaneously"!  (Roughly.)

> 1) The specs use concepts from C++ without furnishing the slightest
> explanation of how those concepts should be understood within the C
> language.
>
> Examples:
> --------
> 7.25.1.3
> TSS_DTOR_ITERATIONS
> which expands to an integer constant expression representing the
> maximum number of times that destructors will be called when a
> thread terminates.
>
> The committee thinks apparently that the term "destructors" is
> common in C so that doesn't need any definition or explanation of what
> that should be in the context of the C language. The term doesn't even
> appear in the index nor is explained anywhere.
>

Hmmm.

>
> 7.25.1.4
> cnd_t
> which is a complete object type that holds an identifier for a
> condition variable;
>
> How can a type "hold an identifier" ??? The committee defines in
> 6.4.2.1.2 an identifier as a sequence of letters that designates
> one or more entities.
> Now, we have the opposite: a type holds an identifier and nowhere
> is explained what that should mean!
>

Hmmm again.

> 2) The proposed functions are absurd.
>
> Take, for instance, nothing less than the thread creation function
> thrd_create:
>
> int thrd_create(thrd_t *thr, thrd_start_t func,void *arg);
>
> As you can see, there are *no arguments that can be passed to the
> underlying operating system* to further specify the newly created
> thread. (The "args" arument is an argument for the thread).
>

I wouldn't use the proposed C1X threads with such expectations.  I'd use 
libraries and interfaces which meet my expectations.

> The pthreads standard (POSIX) proposes an "attributes" argument. The
> Microsoft threads propose a "security attributes" and a set of flags
> that further specify the newly created thread. The C API proposes
> NOTHING so it is impossible to use.
>

Why, there's even "thread impersonation" in at least Windows.  There're 
even "fibers".  So I would assume that for C1X threads, no such 
considerations are portable and thus don't belong in a C Standard.

> Since there is no way to specify the attributes, this function MUST
> use the default attributes that are NOWHERE specified. This means
> that two compiler systems could very well produce two different sets
> of attributes to be passed to the underlying thread creation
> functions so that we would have a differnt behavior for the same
> source compiled in the same machine. This is completely ridiculous!
>

Why is it ridiculous?  Let's pretend for a moment that C1X (or later) 
thread support gives only a minimal and mundane set of capabilities. 
Something to the effect of "now my program doesn't need to follow a 
strictly sequential order of execution."  That seems worth having on any 
platform that could support it (which itself is a concern).  For 
anything else, don't use C threads.

> The mutex creation functions do not specify any security/ownership
> specifications either.
> Anybody can use anything. This will force all
> developers that run in a security sensitive environment to reject
> this specs. C stayed in the single user era.
>

I disagree.  I think it's worth noting that the term "threads" might not 
have a meaning of great value on its own ("_its_", Mr. J. Kuyper, not 
"_it's_"!).  I don't see a reason why "C threads" must encompass "POSIX 
thread" details or "Windows thread" details.  I _certainly_ don't see 
why a developer would attempt to use "portable C threads" with security 
in mind when security itself is platform-dependent!

A microwave doesn't need to worry about carrying access control lists 
with Active Directory SIDs!  But it might like to distract you with an 
LCD dance while it monitors for temperature dangers!

> The specifications are completely unusable in many other functions:
> For instance:
> The thrd_detach function tells the operating system to dispose of
> any resources allocated to the thread identified by thr when that
> thread terminates.
>

Such as a thread descriptor whose storage the kernel might enjoy 
repossessing, perhaps.

> That's new to me. The OS should free all memory allocated by the
> thread? Close all files? This is highly system dependent and
> many systems could very well not do the cleanup until the process
> that created those ressources stops.
>

I agree that that'd seem strange, if that's what the authors' intentions 
are.  Not impossible, mind you.  I would agree that clarification is 
warranted, given your interpretation.

> 3) New types are defined without any specification.
> Example:
> -------
> The "xtime" data type is defined as
> struct xtime { time_t sec; long nanoseconds; };
>
> What is the epoch of the "sec" member? Nobody knows. When you call
> a function using an "xtime" as argument with
> (struct xtime) {5,0}
> means:
> A)
> I call this function with a timeout of five seconds, i.e. the "sec"
> epoch starts running at the instant of function call.
>
> B)
> I call it with a timeout of January first 1970 and five seconds,
> i.e. since the "sec" member is a time_t and time_t variables are
> used to store CALENDAR TIMES (as per difftime specs in 7.26.2.1)
> I specify a timeout that has already expired.
>
> Nowhere in the standard is the "xtime" explained or further described.
> The committee supposes that it suffices to name a member "sec" for
> its meaning to be crystal clear.
>
> I fear that is not the case.
>

Hmmm yet again.

>
> [...more about "time"...]
>
> 5) Error analysis is very difficult.
>
> The proposed functions return the enum value "thrd_error" if
> SOMETHING goes wrong. Impossible to know WHAT did go wrong since
> nowhere is specified if errno should have a value set or how
> to figure out WHAT HAPPENED!!! There is NO WAY that the running
> program can communicate the reasons of failure so that we are
> left in the dark as to why each error happens. The Microsoft API
> specifies GetLastError() and pthreads have errno and other
> mechanisms to further speicify what kind of error happened. This
> specs ignore all that. It doesn't work, now go figure what happens
> during HOURS of debugging!
>

For simple threads, a simple error might be sufficient.  If an 
implementation documents that their "C threads" map to some subset of 
"OS threads," perhaps they'd also provide additional functions.  Else, 
don't try to write portable code that cares about platform-specific errors.

> I am repeating here in an expanded form the critique that I wrote
> in comp.std.c in a message on June 8th 2009. There was no answer then,
> and there has been no change since. ALl errors I pointed out then are
> still in the specs.
>

D'oh.

> I hope this time they will listen or at least justify what they are
> doing. Copy/Paste of Plauger's library docs is not enough to specify
> a change to the C language, excuse me.
>

But wouldn't it be nice to have _some_ kind of thread support in C?  I 
would not appreciate a very sophisticated thread system, and would not 
appreciate injecting POSIX threads into the C Standard.  Please keep it 
Cimple.  It'd be nice to write a simple, portable program with multiple 
threads of execution.

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

#7941

On 07/ 7/11 10:33 PM, jacob navia wrote:
> The committee has decided, for reasons unknown to me (there is no
> explanation why is this necessary anywhere) to go on with the flawed
> Dinkum library specs and proclaim that library as the new standard specs
> for the whole language, what will surely please Plauger but leaves the
> rest of us with a pile of errors.
>
> 1) The specs use concepts from C++ without furnishing the slightest
>      explanation of how those concepts should be understood within the C
>      language.
>
>     Examples:
>     --------
>     7.25.1.3
>     TSS_DTOR_ITERATIONS
>     which expands to an integer constant expression representing the
>      maximum number of times that destructors will be called when a
>      thread terminates.

This term is quite clear in the latest draft, see 7.26.1.4.

>     7.25.1.4
>     cnd_t
>     which is a complete object type that holds an identifier for a
>     condition variable;
>
>    How can a type "hold an identifier" ??? The committee defines in
>     6.4.2.1.2 an identifier as a sequence of letters that designates
>     one or more entities.
>     Now, we have the opposite: a type holds an identifier and nowhere
>     is explained what that should mean!

The type is an implementation detail, just like pthread_t is in POSIX.

> 2) The proposed functions are absurd.
>
>      Take, for instance, nothing less than the thread creation function
>      thrd_create:
>
>      int thrd_create(thrd_t *thr, thrd_start_t func,void *arg);
>
>      As you can see, there are *no arguments that can be passed to the
>      underlying operating system* to further specify the newly created
>      thread. (The "args" arument is an argument for the thread).
>
>      The pthreads standard (POSIX) proposes an "attributes" argument. The
>      Microsoft threads propose a "security attributes" and a set of flags
>      that further specify the newly created thread. The C API proposes
>      NOTHING so it is impossible to use.

In many (most) cases, the default values get passed in pthreads at least.

>      Since there is no way to specify the attributes, this function MUST
>      use the default attributes that are NOWHERE specified. This means
>      that two compiler systems could very well produce two different sets
>      of attributes to be passed to the underlying thread creation
>      functions so that we would have a differnt behavior for the same
>      source compiled in the same machine. This is completely ridiculous!

Agreed, there should be something there, even if it says they are 
implementation defined!

>      The mutex creation functions do not specify any security/ownership
>      specifications either.

Neither does POSIX.

>      The specifications are completely unusable in many other functions:
>      For instance:
>      The thrd_detach function tells the operating system to dispose of
>      any resources allocated to the thread identified by thr when that
>      thread terminates.
>
>      That's new to me. The OS should free all memory allocated by the
>      thread? Close all files? This is highly system dependent and
>      many systems could very well not do the cleanup until the process
>      that created those ressources stops.

Not *by* the thread *to* the thread.

> 3) New types are defined without any specification.
>      Example:
>      -------
>     The "xtime" data type is defined as
>     struct xtime { time_t sec; long nanoseconds; };

Fixed (gone) in current draft.

> 5) Error analysis is very difficult.
>
>      The proposed functions return the enum value "thrd_error" if
>      SOMETHING goes wrong. Impossible to know WHAT did go wrong since
>      nowhere is specified if errno should have a value set or how
>      to figure out WHAT HAPPENED!!! There is NO WAY that the running
>      program can communicate the reasons of failure so that we are
>      left in the dark as to why each error happens. The Microsoft API
>      specifies GetLastError() and pthreads have errno and other
>      mechanisms to further speicify what kind of error happened. This
>      specs ignore all that. It doesn't work, now go figure what happens
>      during HOURS of debugging!

At least in the current draft, the returns are no more or less 
informative than pthread_create (which does not set errno).

> I am repeating here in an expanded form the critique that I wrote
> in comp.std.c in a message on June 8th 2009. There was no answer then,
> and there has been no change since.

But there have, you quoted form an out of date draft!

-- 
Ian Collins

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

#7955

On 07/08/2011 01:10 AM, Ian Collins wrote:
> On 07/ 7/11 10:33 PM, jacob navia wrote:
...
>>     7.25.1.4
>>     cnd_t
>>     which is a complete object type that holds an identifier for a
>>     condition variable;
>>
>>    How can a type "hold an identifier" ??? The committee defines in
>>     6.4.2.1.2 an identifier as a sequence of letters that designates
>>     one or more entities.
>>     Now, we have the opposite: a type holds an identifier and nowhere
>>     is explained what that should mean!
> 
> The type is an implementation detail, just like pthread_t is in POSIX.

Even if it's an implementation detail, it's description should still be
meaningful in the standard; "hold an identifier" doesn't satisfy that
requirement.
-- 
James Kuyper

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

#7959

On 07/ 8/11 11:46 PM, James Kuyper wrote:
> On 07/08/2011 01:10 AM, Ian Collins wrote:
>> On 07/ 7/11 10:33 PM, jacob navia wrote:
> ....
>>>      7.25.1.4
>>>      cnd_t
>>>      which is a complete object type that holds an identifier for a
>>>      condition variable;
>>>
>>>     How can a type "hold an identifier" ??? The committee defines in
>>>      6.4.2.1.2 an identifier as a sequence of letters that designates
>>>      one or more entities.
>>>      Now, we have the opposite: a type holds an identifier and nowhere
>>>      is explained what that should mean!
>>
>> The type is an implementation detail, just like pthread_t is in POSIX.
>
> Even if it's an implementation detail, it's description should still be
> meaningful in the standard; "hold an identifier" doesn't satisfy that
> requirement.

Well the SUS describes pthread_t as a type "Used to identify a thread" 
and pthread_cond_t as a type "Used for condition variables".  It qualify 
them as types that are not required to be arithmetic types, but that's all.

-- 
Ian Collins

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

#7963

On 07/08/2011 07:52 AM, Ian Collins wrote:
> On 07/ 8/11 11:46 PM, James Kuyper wrote:
>> On 07/08/2011 01:10 AM, Ian Collins wrote:
>>> On 07/ 7/11 10:33 PM, jacob navia wrote:
>> ....
>>>>      7.25.1.4
>>>>      cnd_t
>>>>      which is a complete object type that holds an identifier for a
>>>>      condition variable;
>>>>
>>>>     How can a type "hold an identifier" ??? The committee defines in
>>>>      6.4.2.1.2 an identifier as a sequence of letters that designates
>>>>      one or more entities.
>>>>      Now, we have the opposite: a type holds an identifier and nowhere
>>>>      is explained what that should mean!
>>>
>>> The type is an implementation detail, just like pthread_t is in POSIX.
>>
>> Even if it's an implementation detail, it's description should still be
>> meaningful in the standard; "hold an identifier" doesn't satisfy that
>> requirement.
> 
> Well the SUS describes pthread_t as a type "Used to identify a thread" 
> and pthread_cond_t as a type "Used for condition variables".  It qualify 
> them as types that are not required to be arithmetic types, but that's all.

The key point is that "identifier" is a term with a very specific
meaning in the C standard, a meaning that doesn't work in this context.
Replace "that holds an identifier for" with "the value of which
identifies", and I think the problem would be solved.

-- 
James Kuyper

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

#7965

Le 08/07/11 14:23, James Kuyper a écrit :
> The key point is that "identifier" is a term with a very specific
> meaning in the C standard, a meaning that doesn't work in this context.
> Replace "that holds an identifier for" with "the value of which
> identifies", and I think the problem would be solved.
>

Definitely. Now I understand what they wanted to say: the "identifiers"
weren't C identifiers but tokens returned by the underlying system
that identify a thread.


That should be explicit as you propose.

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

#8004

On 07/ 9/11 12:23 AM, James Kuyper wrote:
> On 07/08/2011 07:52 AM, Ian Collins wrote:
>> On 07/ 8/11 11:46 PM, James Kuyper wrote:
>>> On 07/08/2011 01:10 AM, Ian Collins wrote:
>>>> On 07/ 7/11 10:33 PM, jacob navia wrote:
>>> ....
>>>>>       7.25.1.4
>>>>>       cnd_t
>>>>>       which is a complete object type that holds an identifier for a
>>>>>       condition variable;
>>>>>
>>>>>      How can a type "hold an identifier" ??? The committee defines in
>>>>>       6.4.2.1.2 an identifier as a sequence of letters that designates
>>>>>       one or more entities.
>>>>>       Now, we have the opposite: a type holds an identifier and nowhere
>>>>>       is explained what that should mean!
>>>>
>>>> The type is an implementation detail, just like pthread_t is in POSIX.
>>>
>>> Even if it's an implementation detail, it's description should still be
>>> meaningful in the standard; "hold an identifier" doesn't satisfy that
>>> requirement.
>>
>> Well the SUS describes pthread_t as a type "Used to identify a thread"
>> and pthread_cond_t as a type "Used for condition variables".  It qualify
>> them as types that are not required to be arithmetic types, but that's all.
>
> The key point is that "identifier" is a term with a very specific
> meaning in the C standard, a meaning that doesn't work in this context.
> Replace "that holds an identifier for" with "the value of which
> identifies", and I think the problem would be solved.

Ah I see the point now and yes I agree.

-- 
Ian Collins

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

#7973

On 2011-07-08, Ian Collins <ian-news@hotmail.com> wrote:
> On 07/ 8/11 11:46 PM, James Kuyper wrote:
>> Even if it's an implementation detail, it's description should still be
>> meaningful in the standard; "hold an identifier" doesn't satisfy that
>> requirement.

> Well the SUS describes pthread_t as a type "Used to identify a thread" 
> and pthread_cond_t as a type "Used for condition variables".  It qualify 
> them as types that are not required to be arithmetic types, but that's all.

"Hold a thing which identifies" and "hold an identifier" are very different
things when you're talking about the C standard, which has a very precise
definition for "identifier" which trumps the standard English usage.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#7949

["Followup-To:" header set to comp.std.c.]
On 2011-07-07, jacob navia <jacob@spamsink.net> wrote:
> The committee has decided, for reasons unknown to me (there is no 
> explanation why is this necessary anywhere) to go on with the flawed 
> Dinkum library specs and proclaim that library as the new standard specs 
> for the whole language, what will surely please Plauger but leaves the 
> rest of us with a pile of errors.

Let's continue adding to the pile. From N1570:

1)
7.26.1.5: "The enumeration constants are
	mtx_plain
which is passed to mtx_init to create a mutex object that supports neither
timeout nor test and return;"

What is "test and return" and where is it specified? Do mtx_recursive or
mtx_timed or both support "test and return functions"?

2)
7.26.4.1.2: "No threads can be blocked waiting for the mutex pointed to by mtx."
What does this mean? What happens if a thread is waiting to lock a mutex when
it is destroyed? Or is the intent that future mutex operations on destroyed
mutex are guaranteed to return thrd_error? Can destroyed mutex be reinitialized?

3)
7.26.4.2.2: The mtx_init function: "which must have one of the six values:"
The list has four values. What if type argument is not one of the
valid values? Is the behavior undefined or is mtx_init() guaranteed to return
thrd_error?

Is it UB to initialize an already initialized mutex?

Also, I believe this is a conforming implementation of mtx_init():

int
mtx_init(mtx_t *mtx, int type)
{
    return thrd_error;	// "quality of implementation" issue here
}

4)
7.26.4.3.2: "Prior calls to mtx_unlock on the same mutex shall synchronize
with this operation."

What does this mean exactly? What if mtx_unlock() fails? Shoudn't this read
"...calls to successful mtx_unlock..." What does "prior" mean here, in context
of concurrently executing threads?

5)
7.27.1.4: The sentence "The semantics of the members and their normal ranges are
expressed in the comments." appears as part of normative text for struct tm but
in footnote 317 for struct timespec. Is this intentional or just editing error?

What if I initialize struct timespec like this

struct timespec ts = { .tv_sec = 0, .tv_nsec = 999999999+1 };

and pass &ts to any library function that accepts struct timespec arguments?
Is the behavior undefined or am I guaranteed to get thrd_error return value?

Pthreads is a better specification than this because it is precise about when
to return EINVAL and other error codes. With C1X threads there is no way to
find out what went wrong when library returns an error indication and there
are too many possibilities for undefined behavior due to lack of explicit
specification.

-- 
Juha Niskanen

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web