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

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

Trivial C11 threads.h wrapper (public domain)

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

Contents

  Trivial C11 threads.h wrapper (public domain) John Tsiombikas <nuclear@member.fsf.org> - 2012-09-27 03:38 +0000
    Re: Trivial C11 threads.h wrapper (public domain) Keith Thompson <kst-u@mib.org> - 2012-09-26 20:50 -0700
      Re: Trivial C11 threads.h wrapper (public domain) John Tsiombikas <nuclear@member.fsf.org> - 2012-09-27 04:15 +0000
        Re: Trivial C11 threads.h wrapper (public domain) Lorenzo Beretta <lory.fulgi@infinito.it> - 2012-09-27 16:35 +0200
          Re: Trivial C11 threads.h wrapper (public domain) John Tsiombikas <nuclear@member.fsf.org> - 2012-09-27 15:58 +0000
            Re: Trivial C11 threads.h wrapper (public domain) Lorenzo Beretta <lory.fulgi@infinito.it> - 2012-09-27 18:27 +0200
              Re: Trivial C11 threads.h wrapper (public domain) Giorgos Keramidas <keramida@ceid.upatras.gr> - 2012-09-29 18:05 +0200
            Re: Trivial C11 threads.h wrapper (public domain) William Ahern <william@wilbur.25thandClement.com> - 2012-09-28 12:08 -0700
            Re: Trivial C11 threads.h wrapper (public domain) Kaz Kylheku <kaz@kylheku.com> - 2012-09-28 19:38 +0000
              Re: Trivial C11 threads.h wrapper (public domain) William Ahern <william@wilbur.25thandClement.com> - 2012-09-28 13:23 -0700
              Re: Trivial C11 threads.h wrapper (public domain) Lorenzo Beretta <lory.fulgi@infinito.it> - 2012-09-29 18:35 +0200
            Re: Trivial C11 threads.h wrapper (public domain) Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-28 15:50 -0400
              Re: Trivial C11 threads.h wrapper (public domain) Lorenzo Beretta <lory.fulgi@infinito.it> - 2012-09-29 18:41 +0200
    Re: Trivial C11 threads.h wrapper (public domain) Markus Elfring <Markus.Elfring@web.de> - 2012-09-27 13:45 +0200
      Re: Trivial C11 threads.h wrapper (public domain) John Tsiombikas <nuclear@member.fsf.org> - 2012-09-27 16:14 +0000
        Re: Trivial C11 threads.h wrapper (public domain) Markus Elfring <Markus.Elfring@web.de> - 2012-09-28 12:05 +0200
          Re: Trivial C11 threads.h wrapper (public domain) Keith Thompson <kst-u@mib.org> - 2012-09-28 03:39 -0700
          Re: Trivial C11 threads.h wrapper (public domain) James Kuyper <jameskuyper@verizon.net> - 2012-09-28 08:23 -0400
            Re: Trivial C11 threads.h wrapper (public domain) John Tsiombikas <nuclear@member.fsf.org> - 2012-09-28 19:48 +0000
      Re: Trivial C11 threads.h wrapper (public domain) Toby Douglass <a@b.com> - 2012-10-01 20:19 +0200
        Re: Trivial C11 threads.h wrapper (public domain) James Kuyper <jameskuyper@verizon.net> - 2012-10-01 14:37 -0400
        Re: Trivial C11 threads.h wrapper (public domain) Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-10-01 14:38 -0400
        Re: Trivial C11 threads.h wrapper (public domain) Keith Thompson <kst-u@mib.org> - 2012-10-01 14:58 -0700
          Re: Trivial C11 threads.h wrapper (public domain) Shao Miller <sha0.miller@gmail.com> - 2012-12-14 22:31 -0500
    Re: Trivial C11 threads.h wrapper (public domain) Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-28 20:22 +0200
      Re: Trivial C11 threads.h wrapper (public domain) Markus Elfring <Markus.Elfring@web.de> - 2012-09-30 23:13 +0200
        Re: Trivial C11 threads.h wrapper (public domain) Keith Thompson <kst-u@mib.org> - 2012-09-30 14:28 -0700
          Re: Trivial C11 threads.h wrapper (public domain) Jens Gustedt <jens.gustedt@loria.fr> - 2012-10-01 00:37 +0200
            Re: Trivial C11 threads.h wrapper (public domain) Jens Gustedt <jens.gustedt@loria.fr> - 2012-10-01 00:44 +0200
              Re: Trivial C11 threads.h wrapper (public domain) Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-30 19:48 -0400
                Re: Trivial C11 threads.h wrapper (public domain) Jens Gustedt <jens.gustedt@loria.fr> - 2012-10-01 08:26 +0200
            Re: Trivial C11 threads.h wrapper (public domain) Markus Elfring <Markus.Elfring@web.de> - 2012-10-01 11:25 +0200
              Re: Trivial C11 threads.h wrapper (public domain) Jens Gustedt <jens.gustedt@loria.fr> - 2012-10-01 11:47 +0200
                Re: Trivial C11 threads.h wrapper (public domain) Markus Elfring <Markus.Elfring@web.de> - 2012-10-01 12:05 +0200
                  Re: Trivial C11 threads.h wrapper (public domain) Jens Gustedt <jens.gustedt@loria.fr> - 2012-10-01 13:15 +0200
                    Clarification for interface specification "C11 threads.h" Markus Elfring <Markus.Elfring@web.de> - 2012-10-03 11:02 +0200
                      Re: Clarification for interface specification "C11 threads.h" Keith Thompson <kst-u@mib.org> - 2012-10-03 13:29 -0700
                      Re: Clarification for interface specification "C11 threads.h" Jens Gustedt <jens.gustedt@loria.fr> - 2012-10-04 13:35 +0200
                        Re: Clarification for interface specification "C11 threads.h" Markus Elfring <Markus.Elfring@web.de> - 2012-10-12 17:45 +0200
                  Re: Trivial C11 threads.h wrapper (public domain) Noob <root@127.0.0.1> - 2012-10-01 18:10 +0200
                Re: Trivial C11 threads.h wrapper (public domain) Nick Bowler <nbowler@draconx.ca> - 2012-10-01 19:28 +0000
                Re: Trivial C11 threads.h wrapper (public domain) Keith Thompson <kst-u@mib.org> - 2012-10-01 15:19 -0700
                  Re: Trivial C11 threads.h wrapper (public domain) Kaz Kylheku <kaz@kylheku.com> - 2012-10-01 23:57 +0000
                  Re: Trivial C11 threads.h wrapper (public domain) Shao Miller <sha0.miller@gmail.com> - 2012-12-14 22:26 -0500
        Re: Trivial C11 threads.h wrapper (public domain) Jens Gustedt <jens.gustedt@loria.fr> - 2012-10-02 14:48 +0200

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

#26931

On 10/01/2012 02:19 PM, Toby Douglass wrote:
> In article <50643C6A.6020609@web.de>, Markus.Elfring@web.de says...
>> 1. Would you like to provide a "typedef" for each enumeration?
> 
> Enums have a type already

True, though it need not be a nameable type - the tag is optional.

> ... and can only take a value in their range.  

That depend upon what you mean by "their range". Every enumerated type
has a corresponding compatible integer type. I believe that any value
representable in that integer type can also be be stored in the
enumerated type.

> What's the advantage of a typedef? ...

I can't think of any, off-hand, but others may be able to.

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

#26932

On 10/1/2012 2:19 PM, Toby Douglass wrote:
> In article <50643C6A.6020609@web.de>, Markus.Elfring@web.de says...
>> 1. Would you like to provide a "typedef" for each enumeration?
>
> Enums have a type already and can only take a value in their range.

     An enum has a type, yes, but a variable of that type is
not range-restricted.

	enum { FOO=1, BAR=2 } x;
	x = 42;  // legal

     Some see this as a flaw in C, and I'd have to agree that C's
enums are sort of half-baked.  However, it allows things like

	enum { COMMAND=1, DATA=2, STROBE=0x40, RESET=0x80 } flags;
	flags = STROBE | DATA;

> What's the advantage of a typedef?  the disadvantage is extended the
> type space.

     In this instance it's moot.  The source under discussion tries
to mimic C11 thread support for systems that lack C11 but have
Pthreads.  As a C11 imitation, it should not introduce gratuitous
identifiers not called for by the C11 Standard.  (Some, of course,
are unavoidable: The Pthreads-related headers declare names that
the C11 Standard reserves for the programmer's use, and some of
those even have external linkage.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#26941

Toby Douglass <a@b.com> writes:
> In article <50643C6A.6020609@web.de>, Markus.Elfring@web.de says...
>> 1. Would you like to provide a "typedef" for each enumeration?
>
> Enums have a type already and can only take a value in their range.  
> What's the advantage of a typedef?  the disadvantage is extended the 
> type space.

I believe that the intent of the enumeration constants defined by
C11's <threads.h> is not to define enumeration *types*.  It's merely
to provide constants of type int with distinct values.  If this
were C++ rather than C, it's likely that they'd be defined as
"const int" objects -- or, conversely, that the functions they're
passed to would take arguments of an enumeration type.

I presume, though the standard doesn't say so explicitly, that

    mtx_plain, mtx_recursive, mtx_timed

are intended to have distinct values as are

    thrd_timedout, thrd_success, thrd_busy, thrd_error, thrd_nomem

An enumeration type (without a tag or typedef) is an easy way to
achieve that.  Adding a tag and/or typedef would create a type name
that's never actually used.  Using that type for the parameters to
the relevant functions would not provide any type safety.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#29261

On 10/1/2012 17:58, Keith Thompson wrote:
>
> An enumeration type (without a tag or typedef) is an easy way to
> achieve that.  Adding a tag and/or typedef would create a type name
> that's never actually used.  Using that type for the parameters to
> the relevant functions would not provide any type safety.
>

Other than IDEs which show the possible named enum values while you're 
typing an argument or such.

- Shao Miller

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

#26770

Hello,

Am 27.09.2012 05:38, schrieb John Tsiombikas:
> Hello everyone! It's been a long time since I was last on usenet :)
> 
> I was anxious to use the new standard C11 threading features, instead of
> platform-specific APIs, but unfortunately my system libc (GNU libc) does
> not implement that bit that yet.
> So, I wrote a trivial C11 thread wrapper over POSIX threads, and
> released it in the public domain just in case anyone is itching to use
> standard C threading in a new project just like me:
> https://github.com/jtsiomb/c11threads

There is a major flaw in your implementation that concerns the type of
the thread functions. You are simply casting C11 function type

int f(void*)

to the POSIX type

void* f(void*)

That is not only undefined behavior what is concerned C, but also
dangerous. The calling conventions for these type of functions may be
different on a given architecture, e.g returning the int value in a
reserved register and the void* on the stack.

Taking care of that incompatibility between C11 an POSIX threads needs
a bit more care than that, I think, if you want to be portable.

> The wrapper is so thin, I didn't think it made sense to make a proper
> library out of it, so it's just a header file with "static inline"
> functions. Drop it in your project, link with pthread and you're good to
> go.
> 
> Disclaimer: I used a draft of the C11 standard while writting this code,
> since I don't actually have the final document. Feel free to notify me
> of any glaring discrepancies or omissions.

The xtime things are gone in the final version and all is now done
with the time structures as they existed before.

There is already an implementation of C11 threads as a wrapper around
POSIX threads that is publicly available. It is integrated in P99:

http://p99.gforge.inria.fr/

The C11 compatibility wrapper of P99 should be completely interface
compatible to C11 threads. (the include files are named differently,
though.)

Basically it also is a shallow wrapper using inline functions around
POSIX, but in addition P99 also offers
 -  an implementation/wrapper for the atomics
 - of thread local variables
 - _Generic (emulated through a macro)

if they are available (generally through gcc and friends)

Jens

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

#26910

> There is already an implementation of C11 threads as a wrapper around
> POSIX threads that is publicly available.

I would interpret source code like the following as an update candidate.

http://p99.gforge.inria.fr/p99-html/p99__threads_8h_source.html :
...
00633 // 7.26.4 Mutex functions
00634
00638 p99_inline
00639 void mtx_destroy(mtx_t *p00_mtx) {
00640   (void)pthread_mutex_destroy(&P99_ENCP(p00_mtx));
00641 }
...


How do think about to get rid of the cast to the return type "void" in such use
cases?

Regards,
Markus

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

#26915

Markus Elfring <Markus.Elfring@web.de> writes:
>> There is already an implementation of C11 threads as a wrapper around
>> POSIX threads that is publicly available.
>
> I would interpret source code like the following as an update candidate.

I'm not sure what you mean by "update candidate".

> http://p99.gforge.inria.fr/p99-html/p99__threads_8h_source.html :
> ...
> 00633 // 7.26.4 Mutex functions
> 00634
> 00638 p99_inline
> 00639 void mtx_destroy(mtx_t *p00_mtx) {
> 00640   (void)pthread_mutex_destroy(&P99_ENCP(p00_mtx));
> 00641 }
> ...
>
>
> How do think about to get rid of the cast to the return type "void" in
> such use cases?

It doesn't matter much.  The POSIX pthread_mutex_destroy() function
returns an int result; the C11 mtx_destroy() function returns void.
The (void) cast in this particular implementation is probably
there to silence a compiler warning about the result of the call
being discarded.  The semantics are exactly the same with or without
the cast.

Could you be reading more into this than is actually there?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#26916

Am 30.09.2012 23:28, schrieb Keith Thompson:
> Markus Elfring <Markus.Elfring@web.de> writes:
>>> There is already an implementation of C11 threads as a wrapper around
>>> POSIX threads that is publicly available.
>>
>> I would interpret source code like the following as an update candidate.
> 
> I'm not sure what you mean by "update candidate".
> 
>> http://p99.gforge.inria.fr/p99-html/p99__threads_8h_source.html :
>> ...
>> 00633 // 7.26.4 Mutex functions
>> 00634
>> 00638 p99_inline
>> 00639 void mtx_destroy(mtx_t *p00_mtx) {
>> 00640   (void)pthread_mutex_destroy(&P99_ENCP(p00_mtx));
>> 00641 }
>> ...
>>
>>
>> How do think about to get rid of the cast to the return type "void" in
>> such use cases?
> 
> It doesn't matter much.  The POSIX pthread_mutex_destroy() function
> returns an int result; the C11 mtx_destroy() function returns void.
> The (void) cast in this particular implementation is probably
> there to silence a compiler warning about the result of the call
> being discarded.  The semantics are exactly the same with or without
> the cast.

Exactly, in particular there are some linux systems where the headers
are annotated with gcc extensions that make it difficult to ignore the
return of a system function.

And if you (Markus) refer to the fact of "casting a return type", this
is something completely different from "casting a function pointer to
a function type with a different return type". In one case the
compiler is supposed to convert the actual return type into something
different (with well defined rules) and in the other case you would
trick the compiler to believe that the return type would be of a
certain type (live on the stack, in a certain hardware register).

In the particular case of a cast with "(void)" has a special semantic
in the standard (here C11), namely to ignore the value an to evaluate
the expression just for its side effects:

 > 6.3.2.2 void ... If an expression of any other type is evaluated as
 > a void expression, its value or designator is discarded. (A void
 > expression is evaluated for its side effects.)

and then in an example it even explains

 > If a function call is evaluated as an expression statement for its
 > side effects only, the discarding of its value may be made explicit by
 > converting the expression to a void expression by means of a cast

And then, finally, the C11 standard leaves no way to get semantic of a
failed call accros, here. Do you see a way to use the return value in
some way?

Jens

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

#26917

Am 01.10.2012 00:37, schrieb Jens Gustedt:
> Am 30.09.2012 23:28, schrieb Keith Thompson:
>> Markus Elfring <Markus.Elfring@web.de> writes:

>> 00633 // 7.26.4 Mutex functions
>>> 00634
>>> 00638 p99_inline
>>> 00639 void mtx_destroy(mtx_t *p00_mtx) {
>>> 00640   (void)pthread_mutex_destroy(&P99_ENCP(p00_mtx));
>>> 00641 }

> And then, finally, the C11 standard leaves no way to get semantic of a
> failed call accros, here. Do you see a way to use the return value in
> some way?

Ah, thinking of it a bit more, it is actually not "(void)" which is
problematic but the fact that the function may result in errno being
set to a non-zero value. I'll replace by something like

if (pthread_mutex_destroy(&P99_ENCP(p00_mtx))) errno = 0;

Thanks
Jens

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

#26918

On 9/30/2012 6:44 PM, Jens Gustedt wrote:
>[...]
> Ah, thinking of it a bit more, it is actually not "(void)" which is
> problematic but the fact that the function may result in errno being
> set to a non-zero value. I'll replace by something like
>
> if (pthread_mutex_destroy(&P99_ENCP(p00_mtx))) errno = 0;

     This would be a very bad thing to do in an implementation
that is supposed to imitate a Standard C library function.

	7.5p3: "The value of errno in the initial thread is zero
	at program startup [...] but is never set to zero by any
	library function. [...]"

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#26919

Am 01.10.2012 01:48, schrieb Eric Sosman:
> On 9/30/2012 6:44 PM, Jens Gustedt wrote:
>> [...]
>> Ah, thinking of it a bit more, it is actually not "(void)" which is
>> problematic but the fact that the function may result in errno being
>> set to a non-zero value. I'll replace by something like
>>
>> if (pthread_mutex_destroy(&P99_ENCP(p00_mtx))) errno = 0;
> 
>     This would be a very bad thing to do in an implementation
> that is supposed to imitate a Standard C library function.
> 
>     7.5p3: "The value of errno in the initial thread is zero
>     at program startup [...] but is never set to zero by any
>     library function. [...]"
> 

Right. The reason is that I thought that pthread_mutex_destroy could
set errno to some error value. But re-reading the manual page of that
I see that the error code is in the function return. So there is no
need to do that at all.

(Otherwise I would have had to capture errno before the call and to
restore it if the call to pthread_mutex_destroy failed. Expensive.)

Thanks

Jens

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

#26923

> Exactly, in particular there are some linux systems where the headers
> are annotated with gcc extensions that make it difficult to ignore the
> return of a system function.

I would appreciate if such return value ignorance can be avoided.
http://stackoverflow.com/questions/12416604/failing-compilation-if-return-value-is-unused-for-a-certain-type#12416677


> And then, finally, the C11 standard leaves no way to get semantic of a
> failed call accros, here.

I find this information questionable. I get the impression from one of your
articles that you know also alternative approaches.
http://gustedt.wordpress.com/2012/07/15/capture-return-codes-from-library-functions/


> Do you see a way to use the return value in some way?

Yes, of course!   ;-)

How do think about to forward the error code to a log message for a file like
"stderr" eventually?
Would you like to call the function "abort" if a function call like
"pthread_mutex_destroy" failed?

Is the completion of error detection and corresponding exception handling an
open issue also in the affected wrapper implementation?

Regards,
Markus

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

#26924

Hallo Marcus,

Am 01.10.2012 11:25, schrieb Markus Elfring:
>> Exactly, in particular there are some linux systems where the headers
>> are annotated with gcc extensions that make it difficult to ignore the
>> return of a system function.
> 
> I would appreciate if such return value ignorance can be avoided.
> http://stackoverflow.com/questions/12416604/failing-compilation-if-return-value-is-unused-for-a-certain-type#12416677

The problem here is that this is not an interface that I/we design,
but that this is supposed to emulate a C library interface. The
description there is extremely concise, and in particular it doesn't
foresee the possibility of failure of the call. (For other functions
the standard would have some generic phrase "if you pass invalid input
to the function the behavior is undefined".)

>> And then, finally, the C11 standard leaves no way to get semantic of a
>> failed call accros, here.
> 
> I find this information questionable. I get the impression from one of your
> articles that you know also alternative approaches.
> http://gustedt.wordpress.com/2012/07/15/capture-return-codes-from-library-functions/

The wrappers there suppose that the functions *do* give a return
indication that something went wrong and then provide an possible
extension to capture such an error with a try/catch mechanism.

If you'd want to have such a wrapper around the *pthread* functions,
there is no problem, and you could even use P99 tools for that.

I think I can't do that per default, here, since the mtx_destroy
function then would be non-conforming.

But one could definitively think of an optional header that wraps the
pthread calls (and perhaps other POSIX stuff) and put a red tape on
that saying that the resulting code may not be C11 conforming on
certain aspects.

>> Do you see a way to use the return value in some way?
> 
> Yes, of course!   ;-)
> 
> How do think about to forward the error code to a log message for a file like
> "stderr" eventually?
> Would you like to call the function "abort" if a function call like
> "pthread_mutex_destroy" failed?
> 
> Is the completion of error detection and corresponding exception handling an
> open issue also in the affected wrapper implementation?

No, I don't think that this is a general problem, since most of the
C11 function foresee a mechanism to return error conditions. There are
only a few functions like this one that don't have any at all.

What is generally happening, though, is that the error conditions that
C11 foresees are only a subset of what POSIX provides. So sometimes
there might be a loss of information.

Jens

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

#26925

> The problem here is that this is not an interface that I/we design,
> but that this is supposed to emulate a C library interface. The
> description there is extremely concise, and in particular it doesn't
> foresee the possibility of failure of the call. (For other functions
> the standard would have some generic phrase "if you pass invalid input
> to the function the behavior is undefined".)

I would appreciate if members of the involved standardisation committees will
share their advices for proper and unambiguous interpretation of the discussed
specification and corresponding implementation details.


>> Is the completion of error detection and corresponding exception handling an
>> open issue also in the affected wrapper implementation?
> 
> No, I don't think that this is a general problem, since most of the
> C11 function foresee a mechanism to return error conditions. There are
> only a few functions like this one that don't have any at all.
> 
> What is generally happening, though, is that the error conditions that
> C11 foresees are only a subset of what POSIX provides. So sometimes
> there might be a loss of information.

I guess that this feature difference in the programming interfaces will lead to
a lot of more discussions between software developers, reviewers and testers. I
am curious on further clarifications.

Regards,
Markus

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

#26926

Am 01.10.2012 12:05, schrieb Markus Elfring:
>> The problem here is that this is not an interface that I/we design,
>> but that this is supposed to emulate a C library interface. The
>> description there is extremely concise, and in particular it doesn't
>> foresee the possibility of failure of the call. (For other functions
>> the standard would have some generic phrase "if you pass invalid input
>> to the function the behavior is undefined".)
> 
> I would appreciate if members of the involved standardisation committees will
> share their advices for proper and unambiguous interpretation of the discussed
> specification and corresponding implementation details.

You probably could have a point here, in issuing a defect report on
the standard. I think it would certainly be a good idea if the
standard would have such a phrase, this then would allow an
implementation to do what pleases, e.g raise an exception.


>>> Is the completion of error detection and corresponding exception handling an
>>> open issue also in the affected wrapper implementation?
>>
>> No, I don't think that this is a general problem, since most of the
>> C11 function foresee a mechanism to return error conditions. There are
>> only a few functions like this one that don't have any at all.
>>
>> What is generally happening, though, is that the error conditions that
>> C11 foresees are only a subset of what POSIX provides. So sometimes
>> there might be a loss of information.
> 
> I guess that this feature difference in the programming interfaces will lead to
> a lot of more discussions between software developers, reviewers and testers. I
> am curious on further clarifications.

By programming with these thinks myself (and translating code that had
been written for pthread to C11 threads) I found that most of the
differences are minor and can be easily dealt with.

The main difference is really the starting point of this discussion,
the differing function types for threads. And this one is well
justified from the POV of C, int is the type that you'd have to expect
as a return from a thread, just as main returns an int to the
environment.

On my page for possible defects/improvements for C

p99.gforge.inria.fr/defects-and-improvements

I already have a list of useless incompatibilities between C and
C++. Perhaps it would be good to add the same sort of discussion for C
versus POSIX. Since POSIX always tries (or tried so far) to be
compatible with the current C standard, they probably will want to
deal with these new interfaces and try to explain how they work
together.

Jens

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

#26954 — Clarification for interface specification "C11 threads.h"

> The main difference is really the starting point of this discussion,
> the differing function types for threads. And this one is well
> justified from the POV of C, int is the type that you'd have
> to expect as a return from a thread, just as main returns an int
> to the environment.
> 
> On my page for possible defects/improvements for C

I am curious if you will get feedback by standardisation committee members for
your descriptions.
http://p99.gforge.inria.fr/defects-and-improvements/DR-underspecified-thread-functions.html

Did you forward any of them to an "official" communication channel?


Do the discussed functions just use an interface style that we all know from a
function like "free"?
http://pubs.opengroup.org/onlinepubs/9699919799/functions/free.html

Do such standard specifications allow different error handling implementations?

Regards,
Markus

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

#26972 — Re: Clarification for interface specification "C11 threads.h"

Markus Elfring <Markus.Elfring@web.de> writes:
>> The main difference is really the starting point of this discussion,
>> the differing function types for threads. And this one is well
>> justified from the POV of C, int is the type that you'd have
>> to expect as a return from a thread, just as main returns an int
>> to the environment.
>> 
>> On my page for possible defects/improvements for C
>
> I am curious if you will get feedback by standardisation committee
> members for your descriptions.
> http://p99.gforge.inria.fr/defects-and-improvements/DR-underspecified-thread-functions.html
>
> Did you forward any of them to an "official" communication channel?
[...]

Posting to comp.std.c is *slightly* more likely to get the committee's
attention than posting to comp.lang.c.  The committee has no official
relationship with either newsgroup, but comp.std.c has lower traffic and
is likely to have more commmittee members reading it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#27016 — Re: Clarification for interface specification "C11 threads.h"

Hello,

Am 03.10.2012 11:02, schrieb Markus Elfring:
>> The main difference is really the starting point of this discussion,
>> the differing function types for threads. And this one is well
>> justified from the POV of C, int is the type that you'd have
>> to expect as a return from a thread, just as main returns an int
>> to the environment.
>>
>> On my page for possible defects/improvements for C
> 
> I am curious if you will get feedback by standardisation committee members for
> your descriptions.
> http://p99.gforge.inria.fr/defects-and-improvements/DR-underspecified-thread-functions.html
> 
> Did you forward any of them to an "official" communication channel?

I am not sure what channel that would be, the ISO committees don't
seem to be very open to the outside world. But as Keith suggest,
comp.std.c has probably better chances to be read, so I am
crossposting there.

> Do the discussed functions just use an interface style that we all know from a
> function like "free"?
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/free.html
> 
> Do such standard specifications allow different error handling implementations?

Yes, I think so. It clearly defines under what circumstances the
behavior is undefined, so an implementation would be allowed to define
a behavior as it wishes in these cases.

Generally, if you look at the text for free that you are citing, and
compare it with the text about the threads in C11, you'll notice a
difference in quality. C11 certainly lacked some iterations of
discussion and error correction before it went into the standard. In
particular, a better coordination with the POSIX committee would have
been in order concerning threads.

Jens

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

#27186 — Re: Clarification for interface specification "C11 threads.h"

>> I am curious if you will get feedback by standardisation committee members
>> for your descriptions.
>> http://p99.gforge.inria.fr/defects-and-improvements/DR-underspecified-thread-functions.html
>>
>> Did you forward any of them to an "official" communication channel?
> 
> I am not sure what channel that would be, the ISO committees
> don't seem to be very open to the outside world.

Do you get also any useful information by Derek M. Jones occasionally?   ;-)
http://www.knosof.co.uk/cbook/


> Generally, if you look at the text for free that you are citing,
> and compare it with the text about the threads in C11, you'll notice
> a difference in quality. C11 certainly lacked some iterations
> of discussion and error correction before it went into the standard.
> In particular, a better coordination with the POSIX committee
> would have been in order concerning threads.

I see also another update candidate if you compare descriptions for the
functions "pthread_cond_wait" and "cnd_wait".

http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_wait.html :
"...
When using condition variables there is always a Boolean predicate involving
shared variables associated with each condition wait that is true if the thread
should proceed. Spurious wakeups from the pthread_cond_timedwait() or
pthread_cond_wait() functions may occur.
Since the return from pthread_cond_timedwait() or pthread_cond_wait() does not
imply anything about the value of this predicate, the predicate should be
re-evaluated upon such return.
..."

How do you think about further clarification for the handling of "predicates"
and "spurious wakeups" by the current standard specification for the C
programming language?
Do you need not to care for them eventually because they are not mentioned in a
corresponding draft document?
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Regards,
Markus

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

#26929

Markus Elfring wrote:

> I would appreciate if members of the involved standardisation committees will
> share their advices for proper and unambiguous interpretation of the discussed
> specification and corresponding implementation details.

There might be some POSIX members in comp.unix.programmer

There might be some ISO/IEC JTC1/SC22/WG14 members in comp.std.c

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

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

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

csiph-web