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

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

Still no dirent.h in C1X

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

Contents

  Still no dirent.h in C1X David Demelier <demelier.david@gmail.com> - 2011-11-24 04:43 -0800
    Re: Still no dirent.h in C1X Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-11-24 09:19 -0500
    Re: Still no dirent.h in C1X Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-11-25 20:01 +0000
      Re: Still no dirent.h in C1X Ian Collins <ian-news@hotmail.com> - 2011-11-26 09:03 +1300
        Re: Still no dirent.h in C1X Keith Thompson <kst-u@mib.org> - 2011-11-25 12:18 -0800
          Re: Still no dirent.h in C1X Ian Collins <ian-news@hotmail.com> - 2011-11-26 10:14 +1300
      Re: Still no dirent.h in C1X jacob navia <jacob@spamsink.net> - 2011-11-25 21:18 +0100
        Re: Still no dirent.h in C1X Stephen Sprunk <stephen@sprunk.org> - 2011-11-26 13:23 -0600
          Re: Still no dirent.h in C1X jacob navia <jacob@spamsink.net> - 2011-11-26 23:43 +0100
            Re: Still no dirent.h in C1X Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-12-02 22:26 +0000
              Re: Still no dirent.h in C1X John Tsiombikas <nuclear@member.fsf.org> - 2011-12-02 22:35 +0000
              Re: Still no dirent.h in C1X jacob navia <jacob@spamsink.net> - 2011-12-03 00:51 +0100
      Re: Still no dirent.h in C1X Markus Wichmann <nullplan@gmx.net> - 2011-11-25 23:54 +0100
        Re: Still no dirent.h in C1X Richard Damon <news.x.richarddamon@xoxy.net> - 2011-11-25 20:18 -0500
        Re: Still no dirent.h in C1X Seebs <usenet-nospam@seebs.net> - 2011-11-26 07:21 +0000
        Re: Still no dirent.h in C1X Kleuske <kleuske@nowhere.net> - 2011-11-26 11:27 +0000
      Re: Still no dirent.h in C1X Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-25 22:25 -0800
      Re: Still no dirent.h in C1X André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-11-27 01:13 +0100
    Re: Still no dirent.h in C1X Keith Thompson <kst-u@mib.org> - 2011-11-25 12:24 -0800
    Re: Still no dirent.h in C1X Kaz Kylheku <kaz@kylheku.com> - 2011-11-25 20:38 +0000
      Re: Still no dirent.h in C1X Markus Wichmann <nullplan@gmx.net> - 2011-11-26 00:02 +0100
        Re: Still no dirent.h in C1X Kaz Kylheku <kaz@kylheku.com> - 2011-11-26 17:15 +0000
          Re: Still no dirent.h in C1X Lauri Alanko <la@iki.fi> - 2011-11-26 21:36 +0000
        Re: Still no dirent.h in C1X "James" <no@spam.invalid> - 2011-11-26 10:31 -0800
        Re: Still no dirent.h in C1X lawrence.jones@siemens.com - 2011-11-26 22:13 -0500
        Re: Still no dirent.h in C1X James Kuyper <jameskuyper@verizon.net> - 2011-11-27 07:45 -0500
          Re: Still no dirent.h in C1X Kaz Kylheku <kaz@kylheku.com> - 2011-11-27 16:52 +0000
            Re: Still no dirent.h in C1X James Kuyper <jameskuyper@verizon.net> - 2011-11-27 12:29 -0500
              Re: Still no dirent.h in C1X Kaz Kylheku <kaz@kylheku.com> - 2011-11-27 18:48 +0000
                Re: Still no dirent.h in C1X lawrence.jones@siemens.com - 2011-11-27 16:21 -0500
                  Re: Still no dirent.h in C1X John Tsiombikas <nuclear@member.fsf.org> - 2011-11-28 01:57 +0000
                Re: Still no dirent.h in C1X James Kuyper <jameskuyper@verizon.net> - 2011-11-27 20:04 -0500
                Re: Still no dirent.h in C1X Joshua Maurice <joshuamaurice@gmail.com> - 2011-11-28 13:51 -0800
                  Re: Still no dirent.h in C1X Markus Wichmann <nullplan@gmx.net> - 2011-11-30 16:46 +0100
                    Re: Still no dirent.h in C1X James Kuyper <jameskuyper@verizon.net> - 2011-11-30 11:19 -0500
                      Re: Still no dirent.h in C1X Kaz Kylheku <kaz@kylheku.com> - 2011-11-30 16:51 +0000
                    Re: Still no dirent.h in C1X Joshua Maurice <joshuamaurice@gmail.com> - 2011-11-30 13:12 -0800
                      Re: Still no dirent.h in C1X Ian Collins <ian-news@hotmail.com> - 2011-12-01 10:15 +1300
                        Re: Still no dirent.h in C1X Joshua Maurice <joshuamaurice@gmail.com> - 2011-11-30 13:19 -0800
                        Re: Still no dirent.h in C1X Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-12-01 04:45 +0200
          Re: Still no dirent.h in C1X Markus Wichmann <nullplan@gmx.net> - 2011-11-27 23:30 +0100
            Re: Still no dirent.h in C1X James Kuyper <jameskuyper@verizon.net> - 2011-11-28 06:42 -0500
              Re: Still no dirent.h in C1X Markus Wichmann <nullplan@gmx.net> - 2011-11-28 15:09 +0100
    Re: Still no dirent.h in C1X blp@cs.stanford.edu (Ben Pfaff) - 2011-11-25 15:44 -0800

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

#13914

On 25.11.2011 21:38, Kaz Kylheku wrote:
> I haven't looked at the threads in C1X, but it would be ridiculous if it
> was just a copy of <pthread.h> stuff from POSIX.
> 

It is. Basically, if you prefix every function with "pthread_" and spell
out the second part completely ("cnd" -> "cond", "mtx"->"mutex", etc.)
you get the complete POSIX threads library.

Which is funny, because that itself is a library on Linux, wrapping
around system calls. So, up until now the C library wrapped system
calls, and now the C libary wraps the thread library, which wraps the
system calls. Nice job!

CYA,
Markus

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

#13923

On 2011-11-25, Markus Wichmann <nullplan@gmx.net> wrote:
> On 25.11.2011 21:38, Kaz Kylheku wrote:
>> I haven't looked at the threads in C1X, but it would be ridiculous if it
>> was just a copy of <pthread.h> stuff from POSIX.
>> 
>
> It is. Basically, if you prefix every function with "pthread_" and spell
> out the second part completely ("cnd" -> "cond", "mtx"->"mutex", etc.)
> you get the complete POSIX threads library.

That is fucking stupid, but it's what you expect from a committee working on
the N-th revision of a programming language.

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

#13929

In article <20111126090809.429@kylheku.com>,
Kaz Kylheku  <kaz@kylheku.com> wrote:
> On 2011-11-25, Markus Wichmann <nullplan@gmx.net> wrote:
> > On 25.11.2011 21:38, Kaz Kylheku wrote:
> >> I haven't looked at the threads in C1X, but it would be ridiculous if it
> >> was just a copy of <pthread.h> stuff from POSIX.
> >
> > It is. Basically, if you prefix every function with "pthread_" and spell
> > out the second part completely ("cnd" -> "cond", "mtx"->"mutex", etc.)
> > you get the complete POSIX threads library.
> 
> That is fucking stupid, but it's what you expect from a committee working on
> the N-th revision of a programming language.

Maybe you should read Boehm's "Threads cannot be implemented as a
Library" for some rationale: 

http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html

The point of thread support in C1X is not the API for spawning threads
and synchronization primitives: that's evidently lifted quite
straightforwardly from pthreads. The point is 5.1.2.4 in N1570.


Lauri

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

#13924

"Markus Wichmann" <nullplan@gmx.net> wrote in message 
news:ldj5q8-f15.ln1@voyager.wichi.de.vu...
> On 25.11.2011 21:38, Kaz Kylheku wrote:
>> I haven't looked at the threads in C1X, but it would be ridiculous if it
>> was just a copy of <pthread.h> stuff from POSIX.
>>
>
> It is. Basically, if you prefix every function with "pthread_" and spell
> out the second part completely ("cnd" -> "cond", "mtx"->"mutex", etc.)
> you get the complete POSIX threads library.

Pthreads does not provide atomic operations and memory barriers. However, 
C1X does have them. FINALLY!

[...] 

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

#13954

Markus Wichmann <nullplan@gmx.net> wrote:
> On 25.11.2011 21:38, Kaz Kylheku wrote:
> > I haven't looked at the threads in C1X, but it would be ridiculous if it
> > was just a copy of <pthread.h> stuff from POSIX.
> > 
> 
> It is.

No, it is not.  It is similar to pthreads, but that's just because it
provides many of the same capabilities.  It's also similar to Windows
threads for the same reason.  It's intended to be a generic interface
that can be easily implemented on top of any existing thread support
(but particularly POSIX threads and Windows threads).
-- 
Larry Jones

My brain is trying to kill me. -- Calvin

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

#13972

On 11/25/2011 06:02 PM, Markus Wichmann wrote:
> On 25.11.2011 21:38, Kaz Kylheku wrote:
>> I haven't looked at the threads in C1X, but it would be ridiculous if it
>> was just a copy of <pthread.h> stuff from POSIX.
>>
> 
> It is. Basically, if you prefix every function with "pthread_" and spell
> out the second part completely ("cnd" -> "cond", "mtx"->"mutex", etc.)
> you get the complete POSIX threads library.
> 
> Which is funny, because that itself is a library on Linux, wrapping
> around system calls. So, up until now the C library wrapped system
> calls, and now the C libary wraps the thread library, which wraps the
> system calls. Nice job!

For 2/3 of the functions in <threads.h>, I was able to match them up
that way with <pthread.h> functions, with the following exceptions:

From n1570.pdf "Committee Draft — April 12, 2011 ISO/IEC 9899:201x",
section B.25:
> Theads <threads.h>:
> ...
> int mtx_timedlock(mtx_t *restrict mtx,
> const struct timespec *restrict ts);
...
> thrd_t thrd_current(void);
...
> int thrd_sleep(const struct timespec *duration,
> struct timespec *remaining);
...
> void thrd_yield(void);
> int tss_create(tss_t *key, tss_dtor_t dtor);
> void tss_delete(tss_t key);
> void *tss_get(tss_t key);
> int tss_set(tss_t key, void *val);

Could you please identify which <pthread.h> functions correspond to the
above <threads.h> functions?

When I went to http://www3.opengroup.org/unix/, I got the following notice:
> Please note that on Sunday November 27 our servers are undergoing planned maintenance between 00:30 and 10:00 PST and some pages will be temporarily unavailable during that time.

I'm a little two impatient to wait that long. Therefore, for now, I'm
relying upon the contents of pthreads.h on my desktop, which is an
Ubuntu Linux machine. I'm not sure how accurately it conforms to POSIX.
It contains a lot of gcc-specific stuff, which I've removed where I
recognized it. Here's the list of functions prefixed with "pthread_"
that I extracted from that source, excluding those which clearly matched
a <threads.h> function.

> extern pthread_t pthread_self (void) __attribute__ ((const__));
> extern int pthread_attr_init (pthread_attr_t *__attr) ;
> extern int pthread_attr_destroy (pthread_attr_t *__attr);
> extern int pthread_attr_getdetachstate (const pthread_attr_t *__attr,
>      int *__detachstate);
> extern int pthread_attr_setdetachstate (pthread_attr_t *__attr,
>      int __detachstate);
> extern int pthread_attr_getguardsize (const pthread_attr_t *__attr,
>           size_t *__guardsize);
> extern int pthread_attr_setguardsize (pthread_attr_t *__attr,
>           size_t __guardsize);
> extern int pthread_attr_getschedparam (const pthread_attr_t *restrict
>            __attr,
>            struct sched_param *restrict __param);
> extern int pthread_attr_setschedparam (pthread_attr_t *restrict __attr,
>            const struct sched_param *restrict
>            __param);
> extern int pthread_attr_getschedpolicy (const pthread_attr_t *restrict
>      __attr, int *restrict __policy)
> extern int pthread_attr_setschedpolicy (pthread_attr_t *__attr, int __policy);
> extern int pthread_attr_getinheritsched (const pthread_attr_t *restrict
>       __attr, int *restrict __inherit);
> extern int pthread_attr_setinheritsched (pthread_attr_t *__attr,
>       int __inherit);
> extern int pthread_attr_getscope (const pthread_attr_t *restrict __attr, int *restrict __scope);
> extern int pthread_attr_setscope (pthread_attr_t *__attr, int __scope);
> extern int pthread_attr_getstackaddr (const pthread_attr_t *restrict
>           __attr, void **restrict __stackaddr);
> extern int pthread_attr_setstackaddr (pthread_attr_t *__attr,
>           void *__stackaddr);
> extern int pthread_attr_getstacksize (const pthread_attr_t *restrict
>           __attr, size_t *restrict __stacksize);
> extern int pthread_attr_setstacksize (pthread_attr_t *__attr,
>           size_t __stacksize);
> extern int pthread_setschedparam (pthread_t __target_thread, int __policy, const struct sched_param *__param);
> extern int pthread_getschedparam (pthread_t __target_thread,
>       int *restrict __policy,
>       struct sched_param *restrict __param);
> extern int pthread_setschedprio (pthread_t __target_thread, int __prio);
> extern int pthread_setcancelstate (int __state, int *__oldstate);
> extern int pthread_setcanceltype (int __type, int *__oldtype);
> extern int pthread_cancel (pthread_t __th);
> extern void pthread_testcancel (void);
> extern int pthread_mutex_getprioceiling (const pthread_mutex_t *
>       restrict __mutex,
>       int *restrict __prioceiling);
> extern int pthread_mutex_setprioceiling (pthread_mutex_t *restrict __mutex,
>       int __prioceiling,
>       int *restrict __old_ceiling);
> extern int pthread_mutexattr_init (pthread_mutexattr_t *__attr);
> extern int pthread_mutexattr_destroy (pthread_mutexattr_t *__attr);
> extern int pthread_mutexattr_getpshared (const pthread_mutexattr_t *
>       restrict __attr,
>       int *restrict __pshared);
> extern int pthread_mutexattr_setpshared (pthread_mutexattr_t *__attr,
>       int __pshared);
> extern int pthread_mutexattr_getprotocol (const pthread_mutexattr_t *
>        restrict __attr,
>        int *restrict __protocol));
> extern int pthread_mutexattr_setprotocol (pthread_mutexattr_t *__attr,
>        int __protocol);
> extern int pthread_mutexattr_getprioceiling (const pthread_mutexattr_t *
>           restrict __attr,
>           int *restrict __prioceiling);
> extern int pthread_mutexattr_setprioceiling (pthread_mutexattr_t *__attr,
>           int __prioceiling);
> extern int pthread_condattr_init (pthread_condattr_t *__attr);
> extern int pthread_condattr_destroy (pthread_condattr_t *__attr);
> extern int pthread_condattr_getpshared (const pthread_condattr_t *
>      restrict __attr,
>      int *restrict __pshared);
> extern int pthread_condattr_setpshared (pthread_condattr_t *__attr,
>      int __pshared) ;
> extern int pthread_key_create (pthread_key_t *__key,
>           void (*__destr_function) (void *));
> extern int pthread_key_delete (pthread_key_t __key);
> 
> extern void *pthread_getspecific (pthread_key_t __key);
> extern int pthread_setspecific (pthread_key_t __key,
>     const void *__pointer) ;
> extern int pthread_atfork (void (*__prepare) (void),
>       void (*__parent) (void),
>       void (*__child) (void));

Could you please identify the <threads.h> analogs of those functions?

By my count (and I'll freely admit the possibility of a miscount), there
are 24 functions defined in <threads.h>. I could find no <pthread.h>
analog for 8 of them. I found 61 functions with names starting with
pthread_ in the <pthread.h> on my machine. I could find no <threads.h>
analog for 45 of them. I don't know how many of those might be
extensions to the POSIX standard library. However, your claim that,
simply by modifying the names of the <threads.h> functions, "you get the
complete POSIX threads library." seems very substantially exaggerated.
It doesn't look at all complete to me.
-- 
James Kuyper

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

#13975

On 2011-11-27, James Kuyper <jameskuyper@verizon.net> wrote:
> For 2/3 of the functions in <threads.h>, I was able to match them up
> that way with <pthread.h> functions, with the following exceptions:
>
> From n1570.pdf "Committee Draft — April 12, 2011 ISO/IEC 9899:201x",
> section B.25:
>> Theads <threads.h>:
>> ...
>> int mtx_timedlock(mtx_t *restrict mtx,
>> const struct timespec *restrict ts);
> ...

Hi James,

pthread_mutex_timedlock

http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_timedlock.html

>> thrd_t thrd_current(void);

pthread_self

> ...
>> int thrd_sleep(const struct timespec *duration,

>> struct timespec *remaining);

nanosleep

> ...
>> void thrd_yield(void);

sched_yield

http://pubs.opengroup.org/onlinepubs/009695399/functions/sched_yield.html

>> int tss_create(tss_t *key, tss_dtor_t dtor);
>> void tss_delete(tss_t key);
>> void *tss_get(tss_t key);
>> int tss_set(tss_t key, void *val);

pthread_key_create, pthread_getspecific, etc.

> Could you please identify which <pthread.h> functions correspond to the
> above <threads.h> functions?

As requested.

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

#13977

On 11/27/2011 11:52 AM, Kaz Kylheku wrote:
...
>> Could you please identify which <pthread.h> functions correspond to the
>> above <threads.h> functions?
> 
> As requested.

Any comments on the three dozen other pthread_* functions I listed for
which I could not identify any <thread.h> equivalent? The claim that
<threads.h> corresponds to the complete POSIX threads library was made
by Markus, not you, but he hasn't responded yet, and you have.
-- 
James Kuyper

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

#13982

On 2011-11-27, James Kuyper <jameskuyper@verizon.net> wrote:
> On 11/27/2011 11:52 AM, Kaz Kylheku wrote:
> ...
>>> Could you please identify which <pthread.h> functions correspond to the
>>> above <threads.h> functions?
>> 
>> As requested.
>
> Any comments on the three dozen other pthread_* functions I listed for
> which I could not identify any <thread.h> equivalent?

That's going to be the case because this thread.h is just some toy invention
whereas pthreads is a years-old mature thing that was bred out of real
implementations.

A better way to design a portable threading interface for C would be to take
the subset of POSIX which is matched by <thread.h>, and just refer to the
original document along with the subset.

This way, certain programs with POSIX threads could become ISO C programs
without having to be rewritten.

There are already portable implementations of POSIX threads. If you want POSIX
threads on Win32, you can get it.

Nobody needs new spellings for the same thing.

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

#13984

Kaz Kylheku <kaz@kylheku.com> wrote:
> 
> There are already portable implementations of POSIX threads. If you want POSIX
> threads on Win32, you can get it.

People keep saying that, but no one has yet provided a reference to an
implementation that is usable by normal Windows (Win32) programs.  All
the known examples require some sort of POSIX environment (which is
quite reasonable since pthreads are intimately tied to POSIX; C threads
are not).
-- 
Larry Jones

It's clear I'll never have a career in sports until I learn
to suppress my survival instinct. -- Calvin

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

#13989

On 2011-11-27, lawrence.jones@siemens.com <lawrence.jones@siemens.com> wrote:
> Kaz Kylheku <kaz@kylheku.com> wrote:
>> 
>> There are already portable implementations of POSIX threads. If you want POSIX
>> threads on Win32, you can get it.
>
> People keep saying that, but no one has yet provided a reference to an
> implementation that is usable by normal Windows (Win32) programs.  All
> the known examples require some sort of POSIX environment (which is
> quite reasonable since pthreads are intimately tied to POSIX; C threads
> are not).

Not that it has much relevance in this newsgroup, but I've used this
one: http://sourceware.org/pthreads-win32/ in the past, it works
perfectly as far as I can tell, and I don't have any recollection of it
needing any posix wrappers of any sort (I imagine you refer to something
like cygwin).

I've even written my own pthreads wrapper for win32 threads at one
point. I cannot claim the same level of completeness or correctness as
the implementation I just mentioned, but I definitely didn't need
anything from POSIX to do it, just calls to win32 threading functions.
In fact most of the pthread functions mapped 1-1 to win32 functions
except for condvars which required a more invovled implementation as far
as I remember.

So I can't really see what's so intimately tied to POSIX as you
asserted.

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

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

#13988

On 11/27/2011 01:48 PM, Kaz Kylheku wrote:
...
> There are already portable implementations of POSIX threads. If you want POSIX
> threads on Win32, you can get it.

I'm no expert on Windows programming, I just listened to the debate in
the "C is fixed?" and "The threading specs in the new standard: a new
catastrophe" threads during July and August this year. Many people
participating in those threads knew a lot more about it than I do. Some
experts claimed that POSIX threads only worked in the POSIX subsystem of
Win32, and that most features of Window are NOT available when using
that subsystem. Those people provided links to Microsoft documentation
that appeared to support that claim. Those who's response to the claim
was to say "what POSIX subsystem? I've no idea what you're talking
about" never bothered to address the issues raised by the links that the
first group provided. I found the first group's claims correspondingly
more believable.

The <threads.h> interface was intended to be designed so it could, among
other things, be implemented as a thin wrapper over native threading
features of Windows, as well as other non-POSIX systems. It should
therefore be usable in native Windows mode programs, and not just
programs written for the POSIX subsystem of Win32. I've no idea whether
they achieved that goal.

I never received an answer from anyone to either of my questions to Rui
Maciel on 2011-07-12 in the "C is fixed?" thread. Would you care to
answer them?
-- 
James Kuyper

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

#14013

On Nov 27, 10:48 am, Kaz Kylheku <k...@kylheku.com> wrote:
> On 2011-11-27, James Kuyper <jameskuy...@verizon.net> wrote:
>
> > On 11/27/2011 11:52 AM, Kaz Kylheku wrote:
> > ...
> >>> Could you please identify which <pthread.h> functions correspond to the
> >>> above <threads.h> functions?
>
> >> As requested.
>
> > Any comments on the three dozen other pthread_* functions I listed for
> > which I could not identify any <thread.h> equivalent?
>
> That's going to be the case because this thread.h is just some toy invention
> whereas pthreads is a years-old mature thing that was bred out of real
> implementations.
>
> A better way to design a portable threading interface for C would be to take
> the subset of POSIX which is matched by <thread.h>, and just refer to the
> original document along with the subset.
>
> This way, certain programs with POSIX threads could become ISO C programs
> without having to be rewritten.
>
> There are already portable implementations of POSIX threads. If you want POSIX
> threads on Win32, you can get it.
>
> Nobody needs new spellings for the same thing.

I suspect there were three reasons this was done.

First, political. If you call it pthreads, I suspect Microsoft will
have some additional bias against implementing it. That is bad.

Second, the POSIX spec is woefully underspecified and ambiguous, and
flat out wrong (the try_lock problem), in some areas. The cleanup is
welcome.

Third, it's not well defined what it would mean to implement only part
of POSIX. POSIX depends on the C standard, and we don't want to
introduce a cyclical dependencies of standards if we can help it.

Also, as noted else-thread, we're getting portable memory barriers,
portable atomic exchanges, and such. Thank goodness. Finally.

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

#14078

On 28.11.2011 22:51, Joshua Maurice wrote:
> On Nov 27, 10:48 am, Kaz Kylheku <k...@kylheku.com> wrote:
>> On 2011-11-27, James Kuyper <jameskuy...@verizon.net> wrote:
>>
>>> On 11/27/2011 11:52 AM, Kaz Kylheku wrote:
>>> ...
>>>>> Could you please identify which <pthread.h> functions correspond to the
>>>>> above <threads.h> functions?
>>
>>>> As requested.
>>
>>> Any comments on the three dozen other pthread_* functions I listed for
>>> which I could not identify any <thread.h> equivalent?
>>
>> That's going to be the case because this thread.h is just some toy invention
>> whereas pthreads is a years-old mature thing that was bred out of real
>> implementations.
>>
>> A better way to design a portable threading interface for C would be to take
>> the subset of POSIX which is matched by <thread.h>, and just refer to the
>> original document along with the subset.
>>
>> This way, certain programs with POSIX threads could become ISO C programs
>> without having to be rewritten.
>>
>> There are already portable implementations of POSIX threads. If you want POSIX
>> threads on Win32, you can get it.
>>
>> Nobody needs new spellings for the same thing.
> 
> I suspect there were three reasons this was done.
> 
> First, political. If you call it pthreads, I suspect Microsoft will
> have some additional bias against implementing it. That is bad.
> 

There's no need for M$ to implement pthreads, as there's already a
wrapper library for Win32, wrapping pthreads around Win32 threads. It's
called pthreads-win32.

> Second, the POSIX spec is woefully underspecified and ambiguous, and
> flat out wrong (the try_lock problem), in some areas. The cleanup is
> welcome.
> 

Could you elaborate or give pointers? Google didn't turn up anything
useful for the try_lock problem. Do you mean, that an application that
received a false on return of try_lock() doesn't know whether that was
just a temporary failure (aka Race Condition) or that an application
that constantly calls try_lock() won't be enqueued to the mutex the same
as an application that calls lock() is, leading to a situation where
constantly calling try_lock() results in an endless wait while lock()
would have succeeded by now?

> Third, it's not well defined what it would mean to implement only part
> of POSIX. POSIX depends on the C standard, and we don't want to
> introduce a cyclical dependencies of standards if we can help it.
> 

Yeah, that's why we should propably copy that part of POSIX into C
instead of simply adding pointers.

> Also, as noted else-thread, we're getting portable memory barriers,
> portable atomic exchanges, and such. Thank goodness. Finally.

Yeah, that's definitely a plus. I was getting tired of rewriting the
same algorithms for each CPU someone wanted added.

CYA,
Markus

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

#14080

On 11/30/2011 10:46 AM, Markus Wichmann wrote:
> On 28.11.2011 22:51, Joshua Maurice wrote:
...
> There's no need for M$ to implement pthreads, as there's already a
> wrapper library for Win32, wrapping pthreads around Win32 threads. It's
> called pthreads-win32.

Which only implements a subset of POSIX pthreads. See
<http://sourceware.org/pthreads-win32/conformance.html>

>> Third, it's not well defined what it would mean to implement only part
>> of POSIX. POSIX depends on the C standard, and we don't want to
>> introduce a cyclical dependencies of standards if we can help it.
>>
> 
> Yeah, that's why we should propably copy that part of POSIX into C
> instead of simply adding pointers.

Wrapping it has some advantages over copying it. That way, if POSIX
changes the specification for a component of pthreads, an implementation
can continue to be conforming to both the C and POSIX standards by
working around the change inside the wrapper.

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

#14083

On 2011-11-30, James Kuyper <jameskuyper@verizon.net> wrote:
>> Yeah, that's why we should propably copy that part of POSIX into C
>> instead of simply adding pointers.
>
> Wrapping it has some advantages over copying it. That way, if POSIX
> changes the specification for a component of pthreads, an implementation
> can continue to be conforming to both the C and POSIX standards by
> working around the change inside the wrapper.

POSIX has feature selection macros for different versions of the
interface.

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

#14092

On Nov 30, 7:46 am, Markus Wichmann <nullp...@gmx.net> wrote:
> On 28.11.2011 22:51, Joshua Maurice wrote:
>
> > First, political. If you call it pthreads, I suspect Microsoft will
> > have some additional bias against implementing it. That is bad.
>
> There's no need for M$ to implement pthreads, as there's already a
> wrapper library for Win32, wrapping pthreads around Win32 threads. It's
> called pthreads-win32.

If we want to add pthreads, or a direct copy-paste of pthreads spec to
the C spec, then Microsoft has to implement it, or we bifurcate the
language, and I think we can all agree that would be bad, or at best
neutral to what we have now. (I argue worse because then they might
start ignoring other aspects of the C standard. Gives them precedent,
now that they can never be fully conforming.) I suspect there would be
political pushback from Microsoft because of the names. If we can
avoid that political mess by simply adopting new names, I'm all for
that.

> > Second, the POSIX spec is woefully underspecified and ambiguous, and
> > flat out wrong (the try_lock problem), in some areas. The cleanup is
> > welcome.
>
> Could you elaborate or give pointers? Google didn't turn up anything
> useful for the try_lock problem. Do you mean, that an application that
> received a false on return of try_lock() doesn't know whether that was
> just a temporary failure (aka Race Condition) or that an application
> that constantly calls try_lock() won't be enqueued to the mutex the same
> as an application that calls lock() is, leading to a situation where
> constantly calling try_lock() results in an endless wait while lock()
> would have succeeded by now?

Reordering Constraints for Pthread-Style Locks (2005)
by Hans-j. Boehm
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.85.9908

The paper talks about a lot of things, including this issue. The
really short version is: Because the simple reading of
    int pthread_mutex_trylock(pthread_mutex_t *mutex);
    http://pubs.opengroup.org/onlinepubs/007904875/functions/pthread_mutex_lock.html
guarantees that pthread_mutex_trylock will acquire the mutex iff no
other thread currently has it, and thus pthread_mutex_trylock will
fail to acquire iff another thread currently has it, and the simple
rules of how threading without race conditions is basically
"expression" interleavings, then we can write some "interesting" code
that that assumes certain memory operations are visible in this thread
when trylock returns failure. However, as pthreads is commonly
implemented, this is very not true.

C++11 and C1x fix this by allowing trylock to fail spuriously (and
properly documenting the acquire and release semantics of
acquire_mutex and release_mutex). When trylock returns failure in C+
+11 / C1x, this gives you no useful information; another thread may
have the mutex, and it's possible currently no thread has the mutex.
In practice, it won't be implemented to randomly fail, but the formal
specification of allowing spurious failures (along with properly
documenting acquire and release semantics) remove these troublesome
executions which abuse trylock.

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

#14093

On 12/ 1/11 10:12 AM, Joshua Maurice wrote:
> On Nov 30, 7:46 am, Markus Wichmann<nullp...@gmx.net>  wrote:
>> On 28.11.2011 22:51, Joshua Maurice wrote:
>>
>>> First, political. If you call it pthreads, I suspect Microsoft will
>>> have some additional bias against implementing it. That is bad.
>>
>> There's no need for M$ to implement pthreads, as there's already a
>> wrapper library for Win32, wrapping pthreads around Win32 threads. It's
>> called pthreads-win32.
>
> If we want to add pthreads, or a direct copy-paste of pthreads spec to
> the C spec, then Microsoft has to implement it, or we bifurcate the
> language, and I think we can all agree that would be bad, or at best
> neutral to what we have now. (I argue worse because then they might
> start ignoring other aspects of the C standard. Gives them precedent,
> now that they can never be fully conforming.) I suspect there would be
> political pushback from Microsoft because of the names. If we can
> avoid that political mess by simply adopting new names, I'm all for
> that.

Haven't they already ignored C99?

-- 
Ian Collins

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

#14094

On Nov 30, 1:15 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 12/ 1/11 10:12 AM, Joshua Maurice wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 30, 7:46 am, Markus Wichmann<nullp...@gmx.net>  wrote:
> >> On 28.11.2011 22:51, Joshua Maurice wrote:
>
> >>> First, political. If you call it pthreads, I suspect Microsoft will
> >>> have some additional bias against implementing it. That is bad.
>
> >> There's no need for M$ to implement pthreads, as there's already a
> >> wrapper library for Win32, wrapping pthreads around Win32 threads. It's
> >> called pthreads-win32.
>
> > If we want to add pthreads, or a direct copy-paste of pthreads spec to
> > the C spec, then Microsoft has to implement it, or we bifurcate the
> > language, and I think we can all agree that would be bad, or at best
> > neutral to what we have now. (I argue worse because then they might
> > start ignoring other aspects of the C standard. Gives them precedent,
> > now that they can never be fully conforming.) I suspect there would be
> > political pushback from Microsoft because of the names. If we can
> > avoid that political mess by simply adopting new names, I'm all for
> > that.
>
> Haven't they already ignored C99?

I don't know. Have they? Then again, I think a lot of people have.
Still, I would think no reason to give them more excuses. So, maybe my
point is wrong in its supposed weight.

I'm still a very big fan of actual formal semantics, which is more or
less required when we start doing low level atomics. I'm specifically
a very big fan of how readable and understandable it is. (It's still
near impossible to reason about for anything but very small examples,
but I suspect it's a lot better than some of the hardware docs.)

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

#14122

Ian Collins <ian-news@hotmail.com> writes:
> On 12/ 1/11 10:12 AM, Joshua Maurice wrote:
> > On Nov 30, 7:46 am, Markus Wichmann<nullp...@gmx.net>  wrote:
> >> On 28.11.2011 22:51, Joshua Maurice wrote:
> >>
> >>> First, political. If you call it pthreads, I suspect Microsoft will
> >>> have some additional bias against implementing it. That is bad.
> >>
> >> There's no need for M$ to implement pthreads, as there's already a
> >> wrapper library for Win32, wrapping pthreads around Win32 threads. It's
> >> called pthreads-win32.
> >
> > If we want to add pthreads, or a direct copy-paste of pthreads spec to
> > the C spec, then Microsoft has to implement it, or we bifurcate the
> > language, and I think we can all agree that would be bad, or at best
> > neutral to what we have now. (I argue worse because then they might
> > start ignoring other aspects of the C standard. Gives them precedent,
> > now that they can never be fully conforming.) I suspect there would be
> > political pushback from Microsoft because of the names. If we can
> > avoid that political mess by simply adopting new names, I'm all for
> > that.
> 
> Haven't they already ignored C99?

In totality, perhaps. However, reliance on subsets of C99 is far from
uncommon.

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

[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