Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > The threading specs in the standard: a new catastrophe

Reply
Thread Tools

The threading specs in the standard: a new catastrophe

 
 
Marcin Grzegorczyk
Guest
Posts: n/a
 
      07-09-2011
sfuerst wrote:
> On Jul 8, 12:47 pm, "Chris M. Thomasson"<(E-Mail Removed)> wrote:
>> "sfuerst"<(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>> [...]
>>
>>> Assuming you use a CS as a mutex, then the only nontrivial thing to
>>> have is PTHREAD_MUTEX_INITIALIZER. Fortunately, recent versions of
>>> Microsoft windows allow static initialization of these via the
>>> definition:
>>> #define PTHREAD_MUTEX_INITIALIZER {(void*)-1,-1,0,0,0,0}

>>
>> Can you point me to some documentation please?

>
> The CRITICAL_SECTION structure is defined in Winnt.h
>
> Description of what the fields do is described here:
> http://msdn.microsoft.com/en-us/magazine/cc164040.aspx


Note, however, that the article is not an official Microsoft
documentation, and indeed there's an Editor's Note at the top, which
says one should not use such tricks in production code.
--
Marcin Grzegorczyk
 
Reply With Quote
 
 
 
 
Marcin Grzegorczyk
Guest
Posts: n/a
 
      07-09-2011
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
 
Reply With Quote
 
 
 
 
sfuerst
Guest
Posts: n/a
 
      07-10-2011
On Jul 9, 2:55*pm, Marcin Grzegorczyk <(E-Mail Removed)> wrote:
> sfuerst wrote:
> > On Jul 8, 12:47 pm, "Chris M. Thomasson"<(E-Mail Removed)> *wrote:
> >> "sfuerst"<(E-Mail Removed)> *wrote in message
> >>news:(E-Mail Removed)....
> >> [...]

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

>
> >> Can you point me to some documentation please?

>
> > The CRITICAL_SECTION structure is defined in Winnt.h

>
> > Description of what the fields do is described here:
> >http://msdn.microsoft.com/en-us/magazine/cc164040.aspx

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


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

Steven
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      07-10-2011
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

 
Reply With Quote
 
Marcin Grzegorczyk
Guest
Posts: n/a
 
      07-11-2011
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
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      07-11-2011
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
 
Reply With Quote
 
Marcin Grzegorczyk
Guest
Posts: n/a
 
      07-11-2011
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
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      07-12-2011
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
 
Reply With Quote
 
Marcin Grzegorczyk
Guest
Posts: n/a
 
      07-15-2011
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
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      07-16-2011
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: threading in PyQt vs threading in standard library Steven Woody Python 0 01-09-2009 07:48 AM
threading in PyQt vs threading in standard library Steven Woody Python 0 01-09-2009 07:15 AM
REVIEW: "Confronting Catastrophe: A GIS Handbook", R. W. Greene Rob Slade, doting grandpa of Ryan and Trevor Computer Security 0 11-17-2008 10:49 PM
Cooperative threading preemptive threading - a bit confused failure_to@yahoo.co.uk Java 9 12-29-2007 01:10 AM
New Computer Specs Question Nik Schlein Computer Support 9 11-15-2004 06:57 PM



Advertisments