The threading specs in the standard: a new catastrophe

Discussion in 'C Programming' started by jacob navia, Jul 7, 2011.

  1. jacob navia

    jacob navia Guest

    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.

    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.

    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.


    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!

    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.

    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!

    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.

    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.

    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.


    4) The new types aren't connected to the rest of the language.

    How do you convert an "xtime" into a character string?
    Does strftime accept the new type?
    Note that nowhere was specified that time_t shuld be in seconds
    since the creation of the language. Now, the committee decides
    that time_t is in seconds without giving any second thoughts
    to this change. There is a CLOCKS_PER_SEC macro defined in the
    standard a few pages after this specs. Is that obsolete?
    Should we divide the "sec" member by CLOCKS_PER_SECOND to
    obtain the actual seconds?

    Not a word of those problems, nothing. This would be comic
    if it weren't so sad.


    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!

    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.

    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.
    jacob navia, Jul 7, 2011
    #1
    1. Advertising

  2. On 2011-07-07, jacob navia <> wrote:
    > 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.


    Hello Jacob,

    Have you reviewed committee document N1570?
    Wikipedia says this is the latest draft:

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

    I think some of your critique has been answered already. See also

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1571.pdf

    where the committee "agreed in principle" to change struct xtime to
    struct timespec and clarify its semantics to match POSIX more closely.
    This change has been applied to N1570.

    --
    Juha Niskanen
    Juha Niskanen, Jul 7, 2011
    #2
    1. Advertising

  3. jacob navia

    Todd Carnes Guest

    On Thu, 07 Jul 2011 12:33:48 +0200, jacob navia wrote:

    [snip]

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


    [snip]

    I have no idea if you are right or wrong, and don't pretend to know, but
    why would anyone on the standards committee care about one person's
    postings on usenet? I doubt they read the newsgoups.

    Todd
    Todd Carnes, Jul 7, 2011
    #3
  4. jacob navia

    jacob navia Guest

    Le 07/07/11 16:36, christian.bau a écrit :
    > Another rant.
    >
    > Just your point 2: C threads share memory. Since they share memory,
    > you can just about ignore security (there is none).



    Ahh, OK. Both pthreads and Microsoft allow for attributes in their
    create functions. OK. They are both wrong because Mr Christian Bau
    says so.

    The security attributes in Microsoft's version concern the inheritance
    of the newly created thread handles: are they inherited by child
    processes?

    You have just shown us your ignorance.

    > For security, you
    > would need separate processes, and at that point it is really outside
    > the realm of C.


    As far as I know "system()" creates a new process. But apparently you
    think that is "outside the realm of C". OK then.

    > So having no "attributes" for thread creation is Ok
    > with me.


    With you. Not with Microsoft windows or with pthreads.


    > And C threads wouldn't pass "default attributes" to some
    > underlying system, they just behave as defined by the C standard.


    And you think they will not use the underlying operating system or
    or what? The underlying OS implementations REQUIRE those parameters
    so you HAVE to pass something in there.

    > So
    > if you encounter different behavior, then either one implementation is
    > non-conforming, or your expectations of thread behavior are wrong.


    The standard doesn't say if the new thread starts suspended or not,
    Compiler "A" starts the thread in a suspended state, compiler "B"
    starts without suspension. Which is right?

    > Your comments on "thrd_detach" can only be interpreted as a deliberate
    > misunderstanding. Allocated memory and opened files are _not_
    > "resources allocated to the thread".


    no? Then WHAT are those "ressources"? They aren't even specified!

    > They are allocated _by_ some
    > thread _to_ the whole application.


    Depends on the OS.
    jacob navia, Jul 7, 2011
    #4
  5. jacob navia

    jacob navia Guest

    Le 07/07/11 15:12, Todd Carnes a écrit :
    > On Thu, 07 Jul 2011 12:33:48 +0200, jacob navia wrote:
    >
    > [snip]
    >
    >> 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.

    >
    > [snip]
    >
    > I have no idea if you are right or wrong, and don't pretend to know, but
    > why would anyone on the standards committee care about one person's
    > postings on usenet? I doubt they read the newsgoups.
    >
    > Todd


    "They do not read anything, or care about anyone."

    Is that what you want to say?

    Maybe you are just wrong, and they do care about what the community
    thinks or proposes.

    Or maybe you are right, and they live in limbo. Time will tell.
    jacob navia, Jul 7, 2011
    #5
  6. jacob navia

    Jens Gustedt Guest

    Am 07.07.2011 17:09, schrieb jacob navia:
    > You have just shown us your ignorance.


    I don't think that bashing on people will bring your issue forward.

    >> And C threads wouldn't pass "default attributes" to some
    >> underlying system, they just behave as defined by the C standard.

    >
    > And you think they will not use the underlying operating system or
    > or what? The underlying OS implementations REQUIRE those parameters
    > so you HAVE to pass something in there.


    Yes, certainly. An implementation of the C1x stuff has to provide the
    right arguments to the OS implementation of threads, e.g if the the
    underlying implementation is pthread, it has to set the attribute
    argument properly, if the default for pthread is not conforming to
    C1x. I don't see a particular difficulty in that one, it is the C1x
    thrd implementation that has to provide these arguments.

    You would be right in saying that this model is kind of restrictive,
    allowing for only one execution model. In particular it is a pity that
    it doesn't allow to start threads in a detached state.

    > The standard doesn't say if the new thread starts suspended or not,
    > Compiler "A" starts the thread in a suspended state, compiler "B"
    > starts without suspension. Which is right?


    Hm, since it doesn't define the term "suspended state" and supension
    of a thread is only done via a sleep function for a limited time, I
    don't really understand your issue here.

    >> Your comments on "thrd_detach" can only be interpreted as a deliberate
    >> misunderstanding. Allocated memory and opened files are _not_
    >> "resources allocated to the thread".

    >
    > no? Then WHAT are those "ressources"? They aren't even specified!


    Here, a better wording would probably be appropriate. I think
    injecting the word "specific" before "resources" would already be a
    good disambiguation.


    Jens
    Jens Gustedt, Jul 7, 2011
    #6
  7. jacob navia

    jacob navia Guest

    Le 07/07/11 18:00, Jens Gustedt a écrit :
    > Am 07.07.2011 17:09, schrieb jacob navia:
    >> You have just shown us your ignorance.

    >
    > I don't think that bashing on people will bring your issue forward.
    >


    Well, he started his message with

    "Another rant"

    That's OK?

    My tone was appropiate for his tone.


    >>> And C threads wouldn't pass "default attributes" to some
    >>> underlying system, they just behave as defined by the C standard.

    >>
    >> And you think they will not use the underlying operating system or
    >> or what? The underlying OS implementations REQUIRE those parameters
    >> so you HAVE to pass something in there.

    >
    > Yes, certainly. An implementation of the C1x stuff has to provide the
    > right arguments to the OS implementation of threads, e.g if the the
    > underlying implementation is pthread, it has to set the attribute
    > argument properly, if the default for pthread is not conforming to
    > C1x. I don't see a particular difficulty in that one, it is the C1x
    > thrd implementation that has to provide these arguments.
    >
    > You would be right in saying that this model is kind of restrictive,
    > allowing for only one execution model. In particular it is a pity that
    > it doesn't allow to start threads in a detached state.
    >


    Are the threads visible to child processes? Microsoft requires a
    "security attributes" parameter that defines if the thread is inherited
    to child process or not. Compilar "A" under windows decides that the
    threads aren't visible, compiler "B" decides that they are. Which is
    right?

    >> The standard doesn't say if the new thread starts suspended or not,
    >> Compiler "A" starts the thread in a suspended state, compiler "B"
    >> starts without suspension. Which is right?

    >
    > Hm, since it doesn't define the term "suspended state" and supension
    > of a thread is only done via a sleep function for a limited time, I
    > don't really understand your issue here.
    >


    A thread is suspended when the OS doesn't run it and doesn't schedule
    it.

    >>> Your comments on "thrd_detach" can only be interpreted as a deliberate
    >>> misunderstanding. Allocated memory and opened files are _not_
    >>> "resources allocated to the thread".

    >>
    >> no? Then WHAT are those "ressources"? They aren't even specified!

    >
    > Here, a better wording would probably be appropriate. I think
    > injecting the word "specific" before "resources" would already be a
    > good disambiguation.
    >


    It should be clear from the specifications text what those ressources are.
    jacob navia, Jul 7, 2011
    #7
  8. jacob navia

    Wojtek Lerch Guest

    On 07/07/2011 6:33 AM, jacob navia wrote:
    ....
    > 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.


    Do you find fopen() absurd and impossible to use too? Or are file or
    stream attributes (such as the POSIX permission bits, or O_EXCL) less
    important to you than some of the thread attributes that POSIX or
    Windows have?
    Wojtek Lerch, Jul 7, 2011
    #8
  9. On Jul 7, 7:31 pm, Wojtek Lerch <> wrote:
    >
    > Do you find fopen() absurd and impossible to use too?  Or are file or
    > stream attributes (such as the POSIX permission bits, or O_EXCL) less
    > important to you than some of the thread attributes that POSIX or
    > Windows have?
    >

    If it's the only interface to the file system, you may have problems.
    For instance you can't tell the size of a file, you can't scan a
    directory, you can't set read or write permissions or flag it as a
    temporary. You can't lock it from other processes.

    --
    Visit my website
    http://www.malcolmmclean.site11.com/www
    Malcolm McLean, Jul 7, 2011
    #9
  10. jacob navia

    Wojtek Lerch Guest

    On 07/07/2011 12:40 PM, Malcolm McLean wrote:
    > On Jul 7, 7:31 pm, Wojtek Lerch<> wrote:
    >>
    >> Do you find fopen() absurd and impossible to use too? Or are file or
    >> stream attributes (such as the POSIX permission bits, or O_EXCL) less
    >> important to you than some of the thread attributes that POSIX or
    >> Windows have?
    >>

    > If it's the only interface to the file system, you may have problems.


    Or not, depending on what you're trying to do.

    > For instance you can't tell the size of a file, you can't scan a
    > directory, you can't set read or write permissions or flag it as a
    > temporary. You can't lock it from other processes.


    Right; but if you do need to do any of those things, then you can't rely
    on C99 alone. You need to lose some portability and rely on something
    like POSIX or the Windows API or whatever. But that doesn't make
    fopen() absurd or impossible to use -- a lot of code has been written
    that happily uses fopen() without worrying about any of the fancy
    OS-specific stuff.
    Wojtek Lerch, Jul 7, 2011
    #10
  11. jacob navia

    Chad Guest

    On Jul 7, 11:42 am, Wojtek Lerch <> wrote:
    > On 07/07/2011 12:40 PM, Malcolm McLean wrote:
    >
    > > On Jul 7, 7:31 pm, Wojtek Lerch<>  wrote:

    >
    > >> Do you find fopen() absurd and impossible to use too?  Or are file or
    > >> stream attributes (such as the POSIX permission bits, or O_EXCL) less
    > >> important to you than some of the thread attributes that POSIX or
    > >> Windows have?

    >
    > > If it's the only interface to the file system, you may have problems.

    >
    > Or not, depending on what you're trying to do.
    >
    > > For instance you can't tell the size of a file, you can't scan a
    > > directory, you can't set read or write permissions or flag it as a
    > > temporary. You can't lock it from other processes.

    >
    > Right; but if you do need to do any of those things, then you can't rely
    > on C99 alone.  You need to lose some portability and rely on something
    > like POSIX or the Windows API or whatever.  But that doesn't make
    > fopen() absurd or impossible to use -- a lot of code has been written
    > that happily uses fopen() without worrying about any of the fancy
    > OS-specific stuff.


    I was under the impression that having something like fopen() (also)
    work as an interface to a file system would make the function non-
    portable.


    Chad
    Chad, Jul 7, 2011
    #11
  12. jacob navia

    Angel Guest

    On 2011-07-07, Chad <> wrote:
    >
    > I was under the impression that having something like fopen() (also)
    > work as an interface to a file system would make the function non-
    > portable.


    The stream I/O functions cover the basic opening, reading, writing and
    closing of files that nearly all file systems support. For many
    purposes, this is enough. After all, reading and writing is the main
    purpose of most files, yes?

    It doesn't matter what is under the file. If the OS maps certain
    functions to special files (like most Unix variants do for devices and
    directories), it is potentially possible to interface with such things
    by using the stream I/O functions. That doesn't make the stream I/O
    functions themselves unportable.


    --
    "C provides a programmer with more than enough rope to hang himself.
    C++ provides a firing squad, blindfold and last cigarette."
    - seen in comp.lang.c
    Angel, Jul 7, 2011
    #12
  13. jacob navia

    Chad Guest

    On Jul 7, 12:27 pm, Angel <> wrote:
    > On 2011-07-07, Chad <> wrote:
    >
    >
    >
    > > I was under the impression that having something like fopen() (also)
    > > work as an interface to a file system would make the function non-
    > > portable.

    >
    > The stream I/O functions cover the basic opening, reading, writing and
    > closing of files that nearly all file systems support. For many
    > purposes, this is enough. After all, reading and writing is the main
    > purpose of most files, yes?
    >
    > It doesn't matter what is under the file. If the OS maps certain
    > functions to special files (like most Unix variants do for devices and
    > directories), it is potentially possible to interface with such things
    > by using the stream I/O functions. That doesn't make the stream I/O
    > functions themselves unportable.
    >


    For some reason that doesn't sound right. Maybe I'm wrong. Nothing
    personal, but I'm going to wait for either Mr. Keith Thompson or Dr.
    Eric Sosman give their input on this whole thing.
    Chad, Jul 7, 2011
    #13
  14. jacob navia

    Angel Guest

    On 2011-07-07, Chad <> wrote:
    > On Jul 7, 12:27?pm, Angel <> wrote:
    >> On 2011-07-07, Chad <> wrote:
    >>
    >>
    >>
    >> > I was under the impression that having something like fopen() (also)
    >> > work as an interface to a file system would make the function non-
    >> > portable.

    >>
    >> The stream I/O functions cover the basic opening, reading, writing and
    >> closing of files that nearly all file systems support. For many
    >> purposes, this is enough. After all, reading and writing is the main
    >> purpose of most files, yes?
    >>
    >> It doesn't matter what is under the file. If the OS maps certain
    >> functions to special files (like most Unix variants do for devices and
    >> directories), it is potentially possible to interface with such things
    >> by using the stream I/O functions. That doesn't make the stream I/O
    >> functions themselves unportable.
    >>

    >
    > For some reason that doesn't sound right. Maybe I'm wrong. Nothing
    > personal, but I'm going to wait for either Mr. Keith Thompson or Dr.
    > Eric Sosman give their input on this whole thing.


    Maybe I just don't understand your question or concerns, but what in
    this program that writes data from stdin to the Unix null device is so
    wrong that it makes fopen() non-portable?

    It does just what stream I/O is supposed to do: open a file, write stuff
    to it, and close it. That the file happens to be mapped to a device
    doesn't change anything one bit, does it?


    #include <stdio.h>
    #include <stdlib.h>

    int main(void)
    {
    FILE *devnull = fopen("/dev/null", "w");
    if (!devnull)
    return EXIT_FAILURE;

    int data;
    while ((data = fgetc(stdin)) != EOF)
    fputc(data, devnull);

    fclose(devnull);
    return EXIT_SUCCESS;
    }


    (Yes, I know, I don't test the return results of fputc() and fclose().
    Since the (rather silly) purpose of this program is to discard data, I
    didn't think it was important.)


    --
    "C provides a programmer with more than enough rope to hang himself.
    C++ provides a firing squad, blindfold and last cigarette."
    - seen in comp.lang.c
    Angel, Jul 7, 2011
    #14
  15. Replying selectively.

    jacob navia wrote:
    > 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.


    Yes, a proper definition of that term is badly needed. From the current
    text, it is not clear what TSS_DTOR_ITERATIONS really means, or what it
    means for the `dtor` parameter of tss_create() to be null.

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


    Yes, it is a wrong use of the term `identifier`, but that's an editorial
    issue, IMHO. (Larry Jones, are you reading this?)

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


    As Wojtek Lerch already said in this thread, much the same could be said
    about fopen(). Sure, one can bolt various extensions onto the fopen()
    mode string, but one can equally well specify some sort of
    set_attr_for_thrd_create() interface. Either way, it'll be a
    nonstandard extension.

    [...]
    > Since there is no way to specify the attributes, this function MUST
    > use the default attributes that are NOWHERE specified.


    Because they're outside of the scope of the C standard.

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


    Same for <stdio.h> file access functions.

    [...]
    > 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?


    Rephrasing what Christian said: allocated *to* the thread, not *by* it.

    [...]
    > 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!!!


    Same for fopen(), isn't it?

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


    By 7.5p3, any library function - including <threads.h> functions - is
    allowed (but not required) to set errno, unless the function's
    description says otherwise. I imagine that, if the next edition of
    POSIX adopts C1X, it will require that <threads.h> functions set errno
    on failure, as it does for <stdio.h> ones. (Incidentally, pthreads
    functions generally return errno values directly, rather than set errno.)

    To sum this all up: there are defects in the specification, but - IMHO -
    by far not serious enough to call it a "catastrophe".

    Frankly, I'm more worried about <stdatomic.h>. Just to point out two
    most glaring problems:
    * What, exactly, are "generic functions"? (Aren't they supposed to be
    generic macros?)
    * What types the "generic functions" (or macros) are supposed to accept?
    All the types mentioned in 7.17.6? Only the direct types? Or perhaps
    *all* atomic types, including any _Atomic-qualified struct or union
    types? Some of the wording in 7.17.7.5 suggests the latter
    interpretation, which can have important consequences for ABIs.
    --
    Marcin Grzegorczyk
    Marcin Grzegorczyk, Jul 7, 2011
    #15
  16. jacob navia

    Ian Collins Guest

    On 07/ 8/11 04:31 AM, Wojtek Lerch wrote:
    > On 07/07/2011 6:33 AM, jacob navia wrote:
    > ....
    >> 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.

    >
    > Do you find fopen() absurd and impossible to use too? Or are file or
    > stream attributes (such as the POSIX permission bits, or O_EXCL) less
    > important to you than some of the thread attributes that POSIX or
    > Windows have?


    Is really an appropriate analogy? Using fopen or open is an
    implementation detail whereas the choice of thread implementation is a
    pretty fundamental design decision.

    I agree there are similarities. Both filesystem I/O and threading do
    require some degree of awareness of the operating environment, but I'd
    argue that dependency is stronger with threading.

    From a pthreads user's perspective the proposed API is close enough to
    pthreads with default options it be usable. Provided implementations
    provide a means of mixing native and C1x thread, there shouldn't be many
    barriers to their adoption. For example, on Solaris older native
    threads are compatible with pthreads, so the two can be mixed in the
    same application.

    --
    Ian Collins
    Ian Collins, Jul 7, 2011
    #16
  17. jacob navia

    jacob navia Guest

    Le 07/07/11 23:07, Marcin Grzegorczyk a écrit :

    > To sum this all up: there are defects in the specification, but - IMHO -
    > by far not serious enough to call it a "catastrophe".
    >
    > Frankly, I'm more worried about <stdatomic.h>.


    I haven't started with that one.


    Just to point out two
    > most glaring problems:
    > * What, exactly, are "generic functions"? (Aren't they supposed to be
    > generic macros?)
    > * What types the "generic functions" (or macros) are supposed to accept?
    > All the types mentioned in 7.17.6? Only the direct types? Or perhaps
    > *all* atomic types, including any _Atomic-qualified struct or union
    > types? Some of the wording in 7.17.7.5 suggests the latter
    > interpretation, which can have important consequences for ABIs.


    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.

    But if they are going to do this, then let's do it right from the
    start. Because if the specs are shaky, limited and primitive
    nobody will use them and the standard will make a new failure.

    That is the main worry behind my post.
    jacob navia, Jul 7, 2011
    #17
  18. jacob navia

    jameskuyper Guest

    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?
    jameskuyper, Jul 7, 2011
    #18
  19. jacob navia

    sfuerst Guest

    On Jul 7, 3:25 pm, jameskuyper <> 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
    sfuerst, Jul 8, 2011
    #19
  20. jacob navia

    James Kuyper Guest

    On 07/07/2011 07:12 PM, sfuerst wrote:
    > On Jul 7, 3:25�pm, jameskuyper <> 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
    James Kuyper, Jul 8, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. James Kanze

    Re: Threading in new C++ standard

    James Kanze, Apr 16, 2008, in forum: C++
    Replies:
    5
    Views:
    332
    James Kanze
    Apr 18, 2008
  2. Ke Jin
    Replies:
    89
    Views:
    1,518
    red floyd
    May 23, 2008
  3. Szabolcs Ferenczi

    Re: Threading in new C++ standard

    Szabolcs Ferenczi, Apr 17, 2008, in forum: C++
    Replies:
    12
    Views:
    875
    Dmitriy V'jukov
    May 16, 2008
  4. Steven Woody
    Replies:
    0
    Views:
    393
    Steven Woody
    Jan 9, 2009
  5. Steven Woody
    Replies:
    0
    Views:
    432
    Steven Woody
    Jan 9, 2009
Loading...

Share This Page