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

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

The threading specs in the standard: a new catastrophe

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

Contents

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

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

#7950

Am 07.07.2011 23:14, schrieb Ian Collins:
> From a pthreads user's perspective the proposed API is close enough to
> pthreads with default options it be usable.

I find two important features missing though,
PTHREAD_MUTEX_INITIALIZER and PTHREAD_COND_INITIALIZER.  Not having
them will make the initialization of simple critical sections quite
clumbsy.

Or is it tacidly implied in the standard that the default
initialization of static mutexes and conditions will to the right
thing?

Jens

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

#8044

Jens Gustedt wrote:
> Am 07.07.2011 23:14, schrieb Ian Collins:
>>  From a pthreads user's perspective the proposed API is close enough to
>> pthreads with default options it be usable.
>
> I find two important features missing though,
> PTHREAD_MUTEX_INITIALIZER and PTHREAD_COND_INITIALIZER.  Not having
> them will make the initialization of simple critical sections quite
> clumbsy.
>
> Or is it tacidly implied in the standard that the default
> initialization of static mutexes and conditions will to the right
> thing?

No such thing is implied in the draft Standard.  The reason is that some 
existing mutex implementations do not provide static initialization; 
most notably, under Win32, neither mutex objects nor critical section 
objects do (barring some tricks that may break if Microsoft decides to 
change the underlying implementation, again).
-- 
Marcin Grzegorczyk

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

#8067

Am 10.07.2011 00:02, schrieb Marcin Grzegorczyk:
> No such thing is implied in the draft Standard.  The reason is that some
> existing mutex implementations do not provide static initialization;
> most notably, under Win32, neither mutex objects nor critical section
> objects do (barring some tricks that may break if Microsoft decides to
> change the underlying implementation, again).

Hm, I first thought that a once_flag could be used to launch an
initializer function for such statically objects. As such this is not
possible, since the call_once interface doesn't allow the function
parameter to receive an argument.

But an implementation would have to provide call_once & Co. So you'd
have to have
- some sort of atomic read of the once_flag
- the potential to delay all but one threads that stumble into this
  simultaneaously
- the potential to have the very first thread call an initialization
  function

These ingredients could be used equally well to call an mtx_init and
cnd_init on statically initialized objects, I think. Performance cost
of such things should be minor.

Jens

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

#8138

Jens Gustedt wrote:
> Am 10.07.2011 00:02, schrieb Marcin Grzegorczyk:
>> No such thing is implied in the draft Standard.  The reason is that some
>> existing mutex implementations do not provide static initialization;
>> most notably, under Win32, neither mutex objects nor critical section
>> objects do (barring some tricks that may break if Microsoft decides to
>> change the underlying implementation, again).
>
> Hm, I first thought that a once_flag could be used to launch an
> initializer function for such statically objects. As such this is not
> possible, since the call_once interface doesn't allow the function
> parameter to receive an argument.
>
> But an implementation would have to provide call_once & Co. So you'd
> have to have
> - some sort of atomic read of the once_flag
> - the potential to delay all but one threads that stumble into this
>    simultaneaously

Yes; indeed, that's how one implements Win32 critical section 
initialization when explicit initialization is not feasible for some 
reason (and one doesn't want to rely on undocumented tricks).

> These ingredients could be used equally well to call an mtx_init and
> cnd_init on statically initialized objects, I think. Performance cost
> of such things should be minor.

One problem is, what to do if the actual initialization of the mutex 
(which may entail allocation of system resources) fails.  POSIX simply 
states that things should be implemented such that it cannot fail (see 
the Rationale section of 
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_init.html>), 
but it's not realistic to put such a requirement on all implementations; 
and allowing mtx_*lock() to return thrd_nomem would be a divergence from 
the pthreads practice.

Of course, what I just said does not mean WG14 cannot yet reconsider 
this point; I just consider it unlikely.
-- 
Marcin Grzegorczyk

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

#8140

Am 11.07.2011 21:05, schrieb Marcin Grzegorczyk:
> and allowing mtx_*lock() to return thrd_nomem would be a divergence from
> the pthreads practice.

why thrd_nomem?

I think in such a case they should just return the error code that
mtx_init would have returned. mtx_init only has thrd_sucess and
thrd_error as return codes. mtx_lock has exactly the same, mtx_trylock
adds thrd_busy to that. So the error returns of these function would
not have to be reconsidered.

> Of course, what I just said does not mean WG14 cannot yet reconsider
> this point;

I find the argument in the pthread specification about the advatages
of offering static initialization really convincing.

> I just consider it unlikely.

You are probably right. At the end this interface will probably not be
used by the people, even if we'd see some implementation, soon.

But this re-enforces the initial point of this thread (put aside the
polemics) that this interface is not yet mature. It would probably
have been better to just add a definition of "simultaneous execution"
of some sort. This then could have been the basis of the atomic
stuff.

The part on atomic types and functions (macros) is really important in
my point of view, because I am not aware of any standardization of
these operations. This is some gray zone where all compilers and
systems have some extensions.

Jens

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

#8143

Jens Gustedt wrote:
> Am 11.07.2011 21:05, schrieb Marcin Grzegorczyk:
>> and allowing mtx_*lock() to return thrd_nomem would be a divergence from
>> the pthreads practice.
>
> why thrd_nomem?

That's the intended return value when some resources cannot be 
allocated.  But yes, thrd_error would work about as well in practice. 
(In practice, I suspect most existing pthreads code does not even bother 
to check the return value of pthread_mutex_lock().)

[...]
> I find the argument in the pthread specification about the advatages
> of offering static initialization really convincing.

It certainly does simplify things quite a bit.

[...]
> At the end this interface will probably not be
> used by the people, even if we'd see some implementation, soon.

We'll see.  The benefits of having a standard interface may well 
outweigh its limitations.

As for implementation, AFAIK the interface is based on a subset of the 
Dinkumware library.
-- 
Marcin Grzegorczyk

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

#8151

Am 11.07.2011 23:56, schrieb Marcin Grzegorczyk:
> Jens Gustedt wrote:
>> why thrd_nomem?
> 
> That's the intended return value when some resources cannot be
> allocated.

no, not for mtx_init. in n1570 it only has thrd_error as an error
indication.

>  But yes, thrd_error would work about as well in practice.
> (In practice, I suspect most existing pthreads code does not even bother
> to check the return value of pthread_mutex_lock().)

yes. In practice, on hosted environments running out of memory during
initialization is probably nothing that is heard of much.

> As for implementation, AFAIK the interface is based on a subset of the
> Dinkumware library.

I don't think that just one proprietary implementation will contribute
to a wide spread acceptance. You'd need at least one major compiler
implementor adopt it on each side, windows and unix. On the unix side
this'd better be gcc or clang, so something with an open license of
some sort.

Jens

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

#8330

Jens Gustedt wrote:
> Am 11.07.2011 23:56, schrieb Marcin Grzegorczyk:
>> Jens Gustedt wrote:
>>> why thrd_nomem?
>>
>> That's the intended return value when some resources cannot be
>> allocated.
>
> no, not for mtx_init. in n1570 it only has thrd_error as an error
> indication.

I meant the general description of the enumeration constants in 7.26.1.

[...]
>> As for implementation, AFAIK the interface is based on a subset of the
>> Dinkumware library.
>
> I don't think that just one proprietary implementation will contribute
> to a wide spread acceptance. You'd need at least one major compiler
> implementor adopt it on each side, windows and unix. On the unix side
> this'd better be gcc or clang, so something with an open license of
> some sort.

Glibc, rather than GCC.  If the final standard includes the <threads.h> 
as the current draft describes it, I expect it to be implemented pretty 
soon in glibc (after all, it's just a thin wrapper over pthreads).
-- 
Marcin Grzegorczyk

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

#8345

Am 07/16/2011 01:14 AM, schrieb Marcin Grzegorczyk:
> Jens Gustedt wrote:
>> I don't think that just one proprietary implementation will contribute
>> to a wide spread acceptance. You'd need at least one major compiler
>> implementor adopt it on each side, windows and unix. On the unix side
>> this'd better be gcc or clang, so something with an open license of
>> some sort.
> 
> Glibc, rather than GCC.  If the final standard includes the <threads.h>
> as the current draft describes it, I expect it to be implemented pretty
> soon in glibc (after all, it's just a thin wrapper over pthreads).

So you distiguish the threads support from the atomic support? The
real advantage would be to have them both, I think, and they are
closely related.

For atomic most can probably be done in the library respectively in
header files with inline functions (are they allowed to be macros?)
that just map to the gcc builtins. But a direct support of _Atomic
would at least need some integration in the compiler itself.

Jens

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

#8402

Jens Gustedt <Jens.Gustedt@loria.fr> writes:
> But a direct support of _Atomic
> would at least need some integration in the compiler itself.

The work is already being done, for c++0x atomic support, no?

-miles

-- 
Virtues, n. pl. Certain abstentions.

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

#8447

Miles Bader wrote:
> 
> Jens Gustedt <Jens.Gustedt@loria.fr> writes:
> > But a direct support of _Atomic
> > would at least need some integration in the compiler itself.
> 
> The work is already being done, for c++0x atomic support, no?

AFAIK, to the extent of

http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html

regards,
alexander.

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

#8472

Hello,

Am 07/18/2011 09:50 PM, schrieb Alexander Terekhov:
> Miles Bader wrote:
>> The work is already being done, for c++0x atomic support, no?
> 
> AFAIK, to the extent of
> 
> http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html

This is already a start, but not the same as implementing the _Atomic
keyword in C1x, I guess. This goes more in direction of implementing
the atomic macro/functions by the help of builtins.

You'd have to synthesize the correct arithmetic operations for all
primitive types for which the compiler is supposed to support _Atomic.

Jens

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

#8538

Jens Gustedt wrote:
> 
> Hello,
> 
> Am 07/18/2011 09:50 PM, schrieb Alexander Terekhov:
> > Miles Bader wrote:
> >> The work is already being done, for c++0x atomic support, no?
> >
> > AFAIK, to the extent of
> >
> > http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html
> 
> This is already a start, but not the same as implementing the _Atomic
> keyword in C1x, I guess. This goes more in direction of implementing
> the atomic macro/functions by the help of builtins.
> 
> You'd have to synthesize the correct arithmetic operations for all
> primitive types for which the compiler is supposed to support _Atomic.

I think that _Atomic keyword sucks miserably. I also don't like 
C++0x atomics.

I think that atomic loads and stores ought to support the following 
'modes':

  Whether load/store is competing (default) or not. Competing load 
  means that there might be concurrent store (to the same object). 
  Competing store means that there might be concurrent load or 
  store. Non-competing load/store can be performed non-atomically.

  Whether competing load/store needs remote write atomicity (default 
  is no remote write atomicity). A remote-write-atomicity-yes load
  triggers undefined behaivior in the case of concurrent remote-
  write-atomicity-no store.

  Whether load/store has specified reordering constraint (default 
  is no constraint specified) in terms of the following reordering 
  modes:

    Whether preceding loads (in program order) can be reordered 
    across it (can by default).

    Whether preceding stores (in program order) can be reordered 
    across it (can by default).

    Whether subsequent loads (in program order) can be reordered 
    across it (can by default). For load, the set of constrained 
    subsequent loads can be limited to only dependant loads (aka 
    'consume' mode).

    Whether subsequent stores (in program order) can be reordered 
    across it (can by default). For load, there is an implicit 
    reordering constraint regarding dependent stores (no need to 
    specify it).

    A fence/barrier operation can be used to specify reordering 
    constraint using basically the same modes.

regards,
alexander.

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

#8596

Jens Gustedt wrote:
> Am 07/16/2011 01:14 AM, schrieb Marcin Grzegorczyk:
>> Jens Gustedt wrote:
>>> I don't think that just one proprietary implementation will contribute
>>> to a wide spread acceptance. You'd need at least one major compiler
>>> implementor adopt it on each side, windows and unix. On the unix side
>>> this'd better be gcc or clang, so something with an open license of
>>> some sort.
>>
>> Glibc, rather than GCC.  If the final standard includes the<threads.h>
>> as the current draft describes it, I expect it to be implemented pretty
>> soon in glibc (after all, it's just a thin wrapper over pthreads).
>
> So you distiguish the threads support from the atomic support?

The WG14 certainly has agreed they are different things; that's why 
there is __STDC_NO_ATOMICS__ in the first place (earlier drafts had just 
__STDC_NO_THREADS__).

For the rationale, see the WG14 documents N1553 (comment CA 4) and N1558 
(pp.14-15).  In summary, atomics can be useful even without threads 
(e.g. on embedded systems).
-- 
Marcin Grzegorczyk

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

#8601

Marcin Grzegorczyk wrote:
> 
> Jens Gustedt wrote:
> > Am 07/16/2011 01:14 AM, schrieb Marcin Grzegorczyk:
> >> Jens Gustedt wrote:
> >>> I don't think that just one proprietary implementation will contribute
> >>> to a wide spread acceptance. You'd need at least one major compiler
> >>> implementor adopt it on each side, windows and unix. On the unix side
> >>> this'd better be gcc or clang, so something with an open license of
> >>> some sort.
> >>
> >> Glibc, rather than GCC.  If the final standard includes the<threads.h>
> >> as the current draft describes it, I expect it to be implemented pretty
> >> soon in glibc (after all, it's just a thin wrapper over pthreads).
> >
> > So you distiguish the threads support from the atomic support?
> 
> The WG14 certainly has agreed they are different things; that's why
> there is __STDC_NO_ATOMICS__ in the first place (earlier drafts had just
> __STDC_NO_THREADS__).
> 
> For the rationale, see the WG14 documents N1553 (comment CA 4) and N1558

N1555:

"There is a current macro that says if 
you have stdc_no_threads, if that is 
defined, then you don’t need to provide 
the stdcatomic.h header. These are 
different things. Specifically, threads 
belong to the OS and atomics belongs 
to the hardware. In embedded system, 
you want hardware support and not 
have OS come along for the ride. "

> (pp.14-15).  In summary, atomics can be useful even without threads

"Threads and atomics are different 
things. Specifically, threads belong
to the OS and atomics belong to the
hardware. The OS should provide common
locking implementations so that 
different compilers don't do 
incompatible things. In embedded 
system, you want hardware support and
not have OS come along for the ride.
We should separate __STDC_NO_THREADS
from stdatomic.h. We suggest 
__STDCATOMIC__ be defined if the
system provides atomics and the
atomic header.

We would have atomics in all cases,
with or without threads."

<chuckles>

The quoted N1555 et al text above is 
utter nonsense.

Without threads, we already have 
sig_atomic_t.

regards,
alexander.

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

#8624

Am 07/22/2011 09:36 PM, schrieb Alexander Terekhov:
> Without threads, we already have sig_atomic_t.

I don't think that this is a satisfactory interface. Giving guarantees
for load/store operations beyond signal handlers would probably be a
win.

But I agree that having atomic as widely defined as it is is difficult
to understand without a model for threads.

Jens

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

#8638

http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/

regards,
alexander.

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

#9005 — Re: The threading specs in the standard...

FYI:

http://www.cl.cam.ac.uk/~pes20/cppppc/top.pdf
("Clarifying and compiling C/C++ concurrency: from C++0x to POWER")

"Abstract

The upcoming C and C++ revised standards add concurrency to
the languages, for the first time, in the form of a subtle relaxed
memory model (the C++0x model). This aims to permit compiler
optimisation and to accommodate the differing relaxed-memory
behaviours of mainstream multiprocessors, combining simple semantics
for most code with high-performance low-level atomics for
concurrency libraries. We make two contributions:
We first establish two simpler but provably equivalent models
for C++0x, one for the full language and another for the subset
without consume operations. Subsetting further to the fragment
without low-level atomics, we identify a subtlety arising from
atomic initialisation.
We then prove our main result, the correctness of a proposed
compilation scheme of the C++0x concurrency primitives
to POWER assembly, having noted that an earlier proposal was
flawed. (The main ideas apply also to ARM, which has a similar
relaxed memory architecture.)
This should inform the ongoing development of production
compilers for C++0x and C1x, clarifies what properties of the
machine architecture are required, and builds confidence in the
C++0x and POWER semantics."

regards,
alexander.

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

#7885

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

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

#7890

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.

[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