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

Groups > comp.programming.threads > #1092 > unrolled thread

Trivial C11 threads.h wrapper (public domain)

Back to article view | Back to comp.programming.threads

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) 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) 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) 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) Jens Gustedt <jens.gustedt@loria.fr> - 2012-10-02 14:48 +0200

Page 1 of 2  [1] 2  Next page →

#1092 — Trivial C11 threads.h wrapper (public domain)

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

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.

Cheers!

-- 
John Tsiombikas
http://nuclear.mutantstargoat.com/

[toc] | [next] | [standalone]

#1093

John Tsiombikas <nuclear@member.fsf.org> writes:
[...]
> 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 latest draft I'm aware of is
    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
I think it's nearly identical to the released standard.

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

#1094

On 2012-09-27, Keith Thompson <kst-u@mib.org> wrote:
> John Tsiombikas <nuclear@member.fsf.org> writes:
> [...]
>> 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 latest draft I'm aware of is
>     http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
> I think it's nearly identical to the released standard.
>

Thanks, that's a bit more recent than the one I had. I'll go through
them and see if I can spot any relevant differences.

-- 
John Tsiombikas
http://nuclear.mutantstargoat.com/

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

#1099

On 27/09/2012 06:15, John Tsiombikas wrote:
> On 2012-09-27, Keith Thompson<kst-u@mib.org>  wrote:
>> John Tsiombikas<nuclear@member.fsf.org>  writes:
>> [...]
>>> 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 latest draft I'm aware of is
>>      http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>> I think it's nearly identical to the released standard.
>>
>
> Thanks, that's a bit more recent than the one I had. I'll go through
> them and see if I can spot any relevant differences.
>
I haven't read it carefully enough to count as proofreading... most of 
it seem to make sense, except for a couple of things:
1. pthread_create can return EAGAIN, isn't it almost the same as thrd_nomem?
2. pthread_mutex_timedlock sucks badly -- even microsoft got it right!
    Try the following program and try not to scream when you realize 
*why* it's not doing what you'd expect :)



#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;

void *hold(void *arg)
{
     unsigned u = 5;
     pthread_mutex_lock(&m);
     printf( "sleep %u\n", u);
     sleep(u);
     pthread_mutex_unlock(&m);
     return arg;
}

int main()
{
     const int s = 5;
     struct timespec t;
     pthread_t x;

     setvbuf(stdout, (void *)0, _IONBF, 0);

     if(pthread_create(&x, 0, hold, "!") != 0)
         return 111;
     sleep(2);
     printf("Trying: %ds\n", s);
     t.tv_nsec = 0;
     t.tv_sec = s;
     /* puke! */
     printf("timed_lock(%d) = %d\n", s, pthread_mutex_timedlock(&m, &t));
     return 0;
}

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

#1100

On 2012-09-27, Lorenzo Beretta <lory.fulgi@infinito.it> wrote:
> I haven't read it carefully enough to count as proofreading... most of 
> it seem to make sense, except for a couple of things:
> 1. pthread_create can return EAGAIN, isn't it almost the same as thrd_nomem?

I though about that for a bit while writting it, but after reading the
pthreads manpage and the C standard a couple of times, I decided it's
probably not the same error, and I thought it would be best to just
leave thrd_nomem out.  Might be wrong, I'll go through them again.

> 2. pthread_mutex_timedlock sucks badly -- even microsoft got it right!
>     Try the following program and try not to scream when you realize 
> *why* it's not doing what you'd expect :)
>
>      ...
>      const int s = 5;
>      ...
>      t.tv_nsec = 0;
>      t.tv_sec = s;
>      /* puke! */
>      printf("timed_lock(%d) = %d\n", s, pthread_mutex_timedlock(&m, &t));

*gasp* ... it's absolute time ?! I must admit I never used
timedlocks...

I suppose that makes it easier to ask it to try locking the mutex
until next friday at 3 o'clock or something :)


-- 
John Tsiombikas
http://nuclear.mutantstargoat.com/

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

#1102

On 27/09/2012 17:58, John Tsiombikas wrote:
> On 2012-09-27, Lorenzo Beretta<lory.fulgi@infinito.it>  wrote:
>> I haven't read it carefully enough to count as proofreading... most of
>> it seem to make sense, except for a couple of things:
>> 1. pthread_create can return EAGAIN, isn't it almost the same as thrd_nomem?
>
> I though about that for a bit while writting it, but after reading the
> pthreads manpage and the C standard a couple of times, I decided it's
> probably not the same error, and I thought it would be best to just
> leave thrd_nomem out.  Might be wrong, I'll go through them again.
>
>> 2. pthread_mutex_timedlock sucks badly -- even microsoft got it right!
>>      Try the following program and try not to scream when you realize
>> *why* it's not doing what you'd expect :)
>>
>>       ...
>>       const int s = 5;
>>       ...
>>       t.tv_nsec = 0;
>>       t.tv_sec = s;
>>       /* puke! */
>>       printf("timed_lock(%d) = %d\n", s, pthread_mutex_timedlock(&m,&t));
>
> *gasp* ... it's absolute time ?! I must admit I never used
> timedlocks...
>
> I suppose that makes it easier to ask it to try locking the mutex
> until next friday at 3 o'clock or something :)
>
>
Lol yeah. And the best thing is that it seems that mtx_timedlock waits 
"until after the TIME_UTC-based calendar time pointed to by ts" -- they 
looked at pthread_mutex_timedlock and thought "nice! much better than 
select(), poll(), WaifForSingleObjects(), epoll, kqueue, ..."

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

#1114

John Tsiombikas <nuclear@member.fsf.org> wrote:
> On 2012-09-27, Lorenzo Beretta <lory.fulgi@infinito.it> wrote:
> > I haven't read it carefully enough to count as proofreading... most of 
> > it seem to make sense, except for a couple of things:
> > 1. pthread_create can return EAGAIN, isn't it almost the same as thrd_nomem?

> I though about that for a bit while writting it, but after reading the
> pthreads manpage and the C standard a couple of times, I decided it's
> probably not the same error, and I thought it would be best to just
> leave thrd_nomem out.  Might be wrong, I'll go through them again.

> > 2. pthread_mutex_timedlock sucks badly -- even microsoft got it right!
> >     Try the following program and try not to scream when you realize 
> > *why* it's not doing what you'd expect :)
> >
> >      ...
> >      const int s = 5;
> >      ...
> >      t.tv_nsec = 0;
> >      t.tv_sec = s;
> >      /* puke! */
> >      printf("timed_lock(%d) = %d\n", s, pthread_mutex_timedlock(&m, &t));

> *gasp* ... it's absolute time ?! I must admit I never used
> timedlocks...

> I suppose that makes it easier to ask it to try locking the mutex
> until next friday at 3 o'clock or something :)

I believe some implementations support the option to base it on
CLOCK_MONOTONIC.

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

#1115

On 2012-09-27, John Tsiombikas <nuclear@member.fsf.org> wrote:
> *gasp* ... it's absolute time ?! I must admit I never used
> timedlocks...
>
> I suppose that makes it easier to ask it to try locking the mutex
> until next friday at 3 o'clock or something :)

What it allows you to do is resume an interrupted wait, so that the wakeup
still happens at the originally predetermined time.

With absolutely measured suspensions, you can make a thread wake up, say 10
times a second regardless of the duration of the processing that takes place in
betwen the wakeups (so long as it does not overrun the 0.1 second interval).
In one hour, it will wake up exactly 36000 times.

That kind of timing is sometimes required in real-time programming.

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

#1117

On 9/27/2012 11:58 AM, John Tsiombikas wrote:
>  [...]
> *gasp* ... it's absolute time ?! I must admit I never used
> timedlocks...
>
> I suppose that makes it easier to ask it to try locking the mutex
> until next friday at 3 o'clock or something :)

     "Or something."  It certainly makes it easier to set up a
timeout that will fire every dT milliseconds.  Otherwise you'd
have fun computing how much time to wait between "now" [HIGHER-
PRIORITY THREAD RUNS] and [PAGE FAULT] "then."

     (Open)VMS had/has a handy feature: Time-related services
accepted "absolute time" or "relative time" arguments, so the
program could specify "for interval dT" or "until time T" for
any kind of timeout.  Also, the system's clock-adjusting code
knew which kinds of waits were which, so "wait ten seconds"
would wait for ten seconds regardless of adjustments, while
"wait until 23:17:10" would pay attention to them.

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

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

#1120

On 28/09/2012 21:50, Eric Sosman wrote:
> On 9/27/2012 11:58 AM, John Tsiombikas wrote:
>> [...]
>> *gasp* ... it's absolute time ?! I must admit I never used
>> timedlocks...
>>
>> I suppose that makes it easier to ask it to try locking the mutex
>> until next friday at 3 o'clock or something :)
>
> "Or something." It certainly makes it easier to set up a
> timeout that will fire every dT milliseconds. Otherwise you'd
> have fun computing how much time to wait between "now" [HIGHER-
> PRIORITY THREAD RUNS] and [PAGE FAULT] "then."
>
> (Open)VMS had/has a handy feature: Time-related services
> accepted "absolute time" or "relative time" arguments, so the
> program could specify "for interval dT" or "until time T" for
> any kind of timeout. Also, the system's clock-adjusting code
> knew which kinds of waits were which, so "wait ten seconds"
> would wait for ten seconds regardless of adjustments, while
> "wait until 23:17:10" would pay attention to them.
>
In case anyone's interested: windows does both, meaning that some 
functions take relative time, while some others also accept negative 
values meaning absolute time.
Dunno it it's due to the vms heritage.

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

#1096

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

I have looked at your source file.
https://github.com/jtsiomb/c11threads/blob/1fa0de734e204c1096d0dabac84d0c4497318944/c11threads.h

I suggest to consider the following implementation details a bit more.
1. Would you like to provide a "typedef" for each enumeration?

2. How do you think about to complete error detection and corresponding
exception handling?
2.1 Mapping of error codes from the POSIX thread interface to the values that
are specified by the current standard for the C programming language.
2.2 pthread_mutexattr_init/destroy

Regards,
Markus

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

#1101

On 2012-09-27, Markus Elfring <Markus.Elfring@web.de> wrote:
>
> I have looked at your source file.
> https://github.com/jtsiomb/c11threads/blob/1fa0de734e204c1096d0dabac84d0c4497318944/c11threads.h
>
> I suggest to consider the following implementation details a bit more.
> 1. Would you like to provide a "typedef" for each enumeration?

Would I *like* to do that? probably not, but it's not a matter of
preference. Unless I'm much mistaken, the C11 standard dictates int
as the type of the second argument of mtx_init (where all the mtx_
enumerations go), and as the return of all functions that need to
indicate success or failure (thrd_ enumerations).

> 2. How do you think about to complete error detection and corresponding
> exception handling?
> 2.1 Mapping of error codes from the POSIX thread interface to the values that
> are specified by the current standard for the C programming language.

I just went through both docs and tried to map pthread error codes to
corresponding C11-mandated error codes. Those that had no counterpart, I
just ignored, or bundled them all together under thrd_error as
appropriate. Do you propose a different strategy?

> 2.2 pthread_mutexattr_init/destroy

Yes that was the most hairy bit. This mechanism doesn't seem to map
exactly to what C11 wants. For instance the C standard talks about the
possibility of having a mtx_timed | mtx_recursive mutex, but as far as
I can tell with pthreads I can specify either PTHREAD_MUTEX_RECURSIVE or
PTHREAD_MUTEX_TIMED_NP (which is not even standard), but not both.


-- 
John Tsiombikas
http://nuclear.mutantstargoat.com/

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

#1104

> ... probably not, but it's not a matter of preference.
> Unless I'm much mistaken, the C11 standard dictates int as the type of
> the second argument of mtx_init (where all the mtx_ enumerations go),
> and as the return of all functions that need to indicate success
> or failure (thrd_ enumerations).

I suggest generally that a name is assigned to an enumeration. It might also be
a nice service if a "typedef" will be provided for each enumeration so that it
can become easier to reuse them as a data type in customised data structures.


> I just went through both docs and tried to map pthread error codes to
> corresponding C11-mandated error codes. Those that had no counterpart,
> I just ignored, or bundled them all together under thrd_error as
> appropriate. Do you propose a different strategy?

I guess that this implementation detail shows a software design challenge. I do
not like the ignorance of return values.


> Yes that was the most hairy bit. This mechanism doesn't seem to map
> exactly to what C11 wants. For instance the C standard talks about the
> possibility of having a mtx_timed | mtx_recursive mutex, but as far as
> I can tell with pthreads I can specify either PTHREAD_MUTEX_RECURSIVE or
> PTHREAD_MUTEX_TIMED_NP (which is not even standard), but not both.

Thanks that you pointed out such a portability issue.

I would like to point out once again that your function call
"pthread_mutexattr_init" shows the case of an unused return value. I would
prefer complete error detection and corresponding exception handling.

Some functions from the C standard API (like "mtx_destroy") have got the return
type "void". But the called Pthreads function provides an error code eventually.
How do you think about the reaction "abort()" in this use case?

Regards,
Markus

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

#1105

Markus Elfring <Markus.Elfring@web.de> writes:
> John Tsiombikas <nuclear@member.fsf.org> writes:
>> ... probably not, but it's not a matter of preference.
>> Unless I'm much mistaken, the C11 standard dictates int as the type of
>> the second argument of mtx_init (where all the mtx_ enumerations go),
>> and as the return of all functions that need to indicate success
>> or failure (thrd_ enumerations).
>
> I suggest generally that a name is assigned to an enumeration. It
> might also be a nice service if a "typedef" will be provided for each
> enumeration so that it can become easier to reuse them as a data type
> in customised data structures.
[...]

The C standard doesn't provide typedefs for those enumerations.
An implementation that provided one would be intruding on the
user's namespace.  And there's no particular reason for a typedef;
enumeration constants are of type int, not of the enumeration type.

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

#1108

On 09/28/2012 06:05 AM, Markus Elfring wrote:
>> ... probably not, but it's not a matter of preference.
>> Unless I'm much mistaken, the C11 standard dictates int as the type of
>> the second argument of mtx_init (where all the mtx_ enumerations go),
>> and as the return of all functions that need to indicate success
>> or failure (thrd_ enumerations).
> 
> I suggest generally that a name is assigned to an enumeration. It might also be
> a nice service if a "typedef" will be provided for each enumeration so that it
> can become easier to reuse them as a data type in customised data structures.

He's trying to do the best that he can to implement a C99 substitute for
a new feature of C2011. C2011 does NOT specify a typedef name (or even
an enum tag) for the enumeration constants required to be declared in
<threads.h>. An implementation could provide a tag or a typedef or both,
but it can only use a reserved identifier for those purposes. If he used
a reserved identifier for that purpose, it would make his C99 code have
undefined behavior. If he used an identifier that was not reserved, his
substitute would be inappropriately infringing on the user's name space.

>> Yes that was the most hairy bit. This mechanism doesn't seem to map
>> exactly to what C11 wants. For instance the C standard talks about the
>> possibility of having a mtx_timed | mtx_recursive mutex, but as far as
>> I can tell with pthreads I can specify either PTHREAD_MUTEX_RECURSIVE or
>> PTHREAD_MUTEX_TIMED_NP (which is not even standard), but not both.
> 
> Thanks that you pointed out such a portability issue.
> 
> I would like to point out once again that your function call
> "pthread_mutexattr_init" shows the case of an unused return value. I would
> prefer complete error detection and corresponding exception handling.

I agree - mtx_init() should return thrd_error if
pthread_mutexattr_init() returns a non-zero value.

> Some functions from the C standard API (like "mtx_destroy") have got the return
> type "void". But the called Pthreads function provides an error code eventually.
> How do you think about the reaction "abort()" in this use case?

mtx_destroy() has, in itself, well-defined behavior that does not
include calling abort(). However, pthread_mutex_destroy() is only
allowed to fail if "The implementation has detected an attempt to
destroy the object referenced by mutex while it is locked or referenced
(for example, while being used in a pthread_cond_timedwait() or
pthread_cond_wait()) by another thread."

I haven't studied the C2011 threading specification carefully enough to
be certain, but I suspect that if C code using this wrapper library
could set up a situation in which pthread_mutex_destroy() would fail,
that code which does so might itself have undefined behavior, according
to C2011. If so, that would be sufficient to justify having
mtx_destroy() call abort().
-- 
James Kuyper

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

#1116

On 2012-09-28, James Kuyper <jameskuyper@verizon.net> wrote:
>
> I agree - mtx_init() should return thrd_error if
> pthread_mutexattr_init() returns a non-zero value.

Indeed, I overlooked that.

-- 
John Tsiombikas
http://nuclear.mutantstargoat.com/

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

#1151

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.

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

#1152

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]

#1153

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]

#1157

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]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming.threads

csiph-web