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

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

[C/POSIX] pthread_exit()

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

Contents

  [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-20 16:47 +0000
    Re: [C/POSIX] pthread_exit() "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-20 13:42 -0400
      Re: [C/POSIX] pthread_exit() Keith Thompson <kst-u@mib.org> - 2016-07-20 11:33 -0700
      Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-21 10:10 +0000
      Re: [C/POSIX] pthread_exit() Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-22 08:10 -0500
        Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-22 13:42 +0000
          Re: [C/POSIX] pthread_exit() Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-22 09:44 -0500
            Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-22 14:48 +0000
        Re: [C/POSIX] pthread_exit() Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 14:52 +0100
        Re: [C/POSIX] pthread_exit() supercat@casperkitty.com - 2016-07-22 08:51 -0700
        Re: [C/POSIX] pthread_exit() James Kuyper <jameskuyper@verizon.net> - 2016-07-22 13:26 -0400
        Re: [C/POSIX] pthread_exit() Keith Thompson <kst-u@mib.org> - 2016-07-22 10:28 -0700
          Re: [C/POSIX] pthread_exit() Ian Collins <ian-news@hotmail.com> - 2016-07-23 16:12 +1200
          Re: [C/POSIX] pthread_exit() Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-23 16:43 -0500
            Re: [C/POSIX] pthread_exit() "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-23 18:17 -0400
              Re: [C/POSIX] pthread_exit() Keith Thompson <kst-u@mib.org> - 2016-07-23 20:45 -0700
              Re: [C/POSIX] pthread_exit() James Kuyper <jameskuyper@verizon.net> - 2016-07-24 07:27 -0400
                Re: [C/POSIX] pthread_exit() Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-25 15:22 -0500
                  Re: [C/POSIX] pthread_exit() Ian Collins <ian-news@hotmail.com> - 2016-07-26 08:26 +1200
                  Re: [C/POSIX] pthread_exit() "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-25 16:32 -0400
                    Re: [C/POSIX] pthread_exit() Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-25 15:52 -0500
                      Re: [C/POSIX] pthread_exit() "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-25 16:59 -0400
                        Re: [C/POSIX] pthread_exit() Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-25 16:36 -0500
    Re: [C/POSIX] pthread_exit() Johann Klammer <klammerj@NOSPAM.a1.net> - 2016-07-21 11:54 +0200
      Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-22 08:17 +0000
        Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-22 08:47 +0000
    Re: [C/POSIX] pthread_exit() Melzzzzz <mel@zzzzz.com> - 2016-07-23 00:52 +0200
      Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-25 11:43 +0000
        Re: [C/POSIX] pthread_exit() Melzzzzz <mel@zzzzz.com> - 2016-07-25 13:47 +0200
          Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-25 11:58 +0000
            Re: [C/POSIX] pthread_exit() Melzzzzz <mel@zzzzz.com> - 2016-07-25 14:00 +0200
              Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-25 12:18 +0000
                Re: [C/POSIX] pthread_exit() Melzzzzz <mel@zzzzz.com> - 2016-07-25 14:20 +0200
                  Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-25 12:26 +0000
                    Re: [C/POSIX] pthread_exit() Melzzzzz <mel@zzzzz.com> - 2016-07-25 14:28 +0200
                      Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-25 12:35 +0000
                        Re: [C/POSIX] pthread_exit() JKB <jkb@koenigsberg.invalid> - 2016-07-25 13:44 +0000

Page 1 of 2  [1] 2  Next page →

#90673 — [C/POSIX] pthread_exit()

	Hello,

	I'm debugging a huge program that can enter in deadlock on a
	pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.

	Before writing here, I have tried to debug this program with
	valgrind and helgrind without any success. I have tried Purify also.

	Original program is available at :
	http://www.rpl2.net/telechargements.php -> snapshot

	With following test program :

#!/usr/local/bin/rpl -spd
TEST
<<
	0 -> I
	<< do 'TEST2' detach wfproc 'I' incr I disp until false end >>
>>

TEST2
<<
>>

	rpl enters in deadlock after a random number of cycles in do/until
	loop. I have checked all memory access and I haven't found any memory
	corruption. For example, last time I have launched my test program,
	execution stops with :

...
1090390
1090391
1090392
1090393
1090394
1090395
1090396
1090397

	With gdb, I can obtain a backtrace of faulty thread :

(gdb) bt
#0  __lll_lock_wait () at
../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f9ebbb0bb92 in __GI___pthread_mutex_lock (
    mutex=0x7f9ebc674970 <_rtld_global+2352>)
    at ../nptl/pthread_mutex_lock.c:116
#2  0x00007f9ebb1fdbaf in __GI___dl_iterate_phdr
	(callback=0x7f9ebaedae40, 
    data=0x7f9eb9c878b0) at dl-iteratephdr.c:41
#3  0x00007f9ebaedc1be in _Unwind_Find_FDE ()
    from /lib/x86_64-linux-gnu/libgcc_s.so.1
#4  0x00007f9ebaed8bb3 in ?? () from
    /lib/x86_64-linux-gnu/libgcc_s.so.1
#5  0x00007f9ebaed9dd0 in ?? () from
    /lib/x86_64-linux-gnu/libgcc_s.so.1
#6  0x00007f9ebaeda3d6 in _Unwind_ForcedUnwind ()
    from /lib/x86_64-linux-gnu/libgcc_s.so.1
#7  0x00007f9ebbb11ae0 in __GI___pthread_unwind
    (buf=<optimized out>) at unwind.c:126
#8  0x00007f9ebbb0a5a5 in __do_cancel () at pthreadP.h:283
#9  __pthread_exit (value=value@entry=0x0) at pthread_exit.c:28
...

	Each time, one of the pthread_exit() syscall in src/interruptions.c
	enter in deadlock. I have tried to relink my program with -Wl,-z,now
	as I have seen some very similar issue on internet, but it doesn't
	fix my trouble.
	
	How can I debug this mistake ?

	Regards,

	JB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

[toc] | [next] | [standalone]

#90676

On 07/20/2016 12:47 PM, JKB wrote:
> 	Hello,
>
> 	I'm debugging a huge program that can enter in deadlock on a
> 	pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.

As you yourself noted in your subject line, this is a POSIX-specific 
question. As such, you're more likely to find people who can help you if 
you post in a POSIX-specific forum, such as comp.unix.programmer.

C2011 added the new <threads.h> header, and a lot of features to support 
multi-thread programs. If you were to re-writr this program to make use 
of <threads.h> rather than <pthread.h>, then the corresponding question 
about thrd_exit() could be asked here, in a reasonable expectation that 
someone here might be able to answer it.

I, unfortunately, am not that person - I've almost no experience with 
multi-threaded code, and none at all with the <threads.h>.

When you do start talking with people who are likely to have relevant 
knowledge, it would help immensely if you could give them a much simpler 
body of code to examine. I recommend the following approach:

1. Drop a chunk of code that you suspect has nothing to do with the bug, 
preferably as large as possible. I usually start by dropping all code 
that was not apparently executed during the failed test run - such code 
might influence the bug simply by causing the relocation of data that 
was involved in the bug - but if that isn't the case, you've just 
enormously simplified the problem.
If you can't identify any such code, then your example program is as 
ready as it will ever be - post it to the appropriate forum.

2. Do a test run.

3. If the test run failed to demonstrate the problem that you're asking 
about, reinstate the code you dropped in step 1.

4. Go back to step 1 (do not choose the same chunk of code).

There's an important side benefit from following this procedure: you 
often figure out what the problem is before you even get around to 
finishing this procedure. That's because every time you drop some code 
that wasn't expected to affect the bug, and it actually does affect it, 
you learn something important about what the bug is.

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

#90679

"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 07/20/2016 12:47 PM, JKB wrote:
>> 	Hello,
>>
>> 	I'm debugging a huge program that can enter in deadlock on a
>> 	pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.
>
> As you yourself noted in your subject line, this is a POSIX-specific 
> question. As such, you're more likely to find people who can help you if 
> you post in a POSIX-specific forum, such as comp.unix.programmer.

comp.programming.threads might also be a good place to post.

I just took a look, and it consists mostly of articles by "Ramine".
After killfiling him, it doesn't look the newsgroup is very active these
days, but there have been a few on-topic posts in the last few weeks or
months.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#90717

	Thanks a lot for your answer. I will try on another newsgroup.

	Regards,

	JB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

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

#90779

On 7/20/16 12:42 PM, James R. Kuyper wrote:
> On 07/20/2016 12:47 PM, JKB wrote:
>>     Hello,
>>
>>     I'm debugging a huge program that can enter in deadlock on a
>>     pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.

clang has some pretty get sanitizers now (even if you prefer gcc most
of the time for some bizarre reason, it's worth using the sanitizers,
especially the threading one if your platform supports them. I'm
pretty sure BSD does if not Linux.

>
> As you yourself noted in your subject line, this is a POSIX-specific
> question. As such, you're more likely to find people who can help you if
> you post in a POSIX-specific forum, such as comp.unix.programmer.

Most of the formerly useful Usenet groups have become practically
worthless, including the threads specific one which used to be quite
active with real discussions about threading.

> C2011 added the new <threads.h> header, and a lot of features to support
> multi-thread programs. If you were to re-writr this program to make use
> of <threads.h> rather than <pthread.h>, then the corresponding question
> about thrd_exit() could be asked here, in a reasonable expectation that
> someone here might be able to answer it.

I can't think of a single reason why anyone would prefer to use that
ridiculous stuff in C11 for threading. pthreads is already there and
well vetted.



-- 
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me 
directly)

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

#90780

Le Fri, 22 Jul 2016 08:10:34 -0500,
Randy Howard <rhoward.mx@EverybodyUsesIt.com> écrivait :
> On 7/20/16 12:42 PM, James R. Kuyper wrote:
>> On 07/20/2016 12:47 PM, JKB wrote:
>>>     Hello,
>>>
>>>     I'm debugging a huge program that can enter in deadlock on a
>>>     pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.
>
> clang has some pretty get sanitizers now (even if you prefer gcc most
> of the time for some bizarre reason, it's worth using the sanitizers,
> especially the threading one if your platform supports them. I'm
> pretty sure BSD does if not Linux.

	I have tried gcc sanitizer (-fsanitize=address and thread). I have
	found a minor error with -fsanitize=thread (but without any
	consequence). I use gcc as I need a fortran compiler.

	I suppose there is somewhere a bug in my code, but I'm not able to
	find it. If pthread_exit() stops on internal mutex, I suppose that
	pthread_t structure is corrupted. But I haven't found any memory or
	heap corruption. It's a random bug and I have tried to find a race
	condition without success.

	My code uses also SIGUSR1/2 and SIGALRM. But I have blocked all
	signals in faulty thread.

	Regards,

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

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

#90785

On 7/22/16 8:42 AM, JKB wrote:
> 	I have tried gcc sanitizer (-fsanitize=address and thread). I have
> 	found a minor error with -fsanitize=thread (but without any
> 	consequence).

Fair enough. It's not black magic, but it can be helpful. This is the
main issue with threaded programming. It takes a lot of careful planning
up front, or a LOT of painful debugging later on. Sometimes both. :-)

> 	I suppose there is somewhere a bug in my code, but I'm not able to
> 	find it. If pthread_exit() stops on internal mutex, I suppose that
> 	pthread_t structure is corrupted. But I haven't found any memory or
> 	heap corruption. It's a random bug and I have tried to find a race
> 	condition without success.

Well, I'm sure none of us can guess, and it's probably too large (or
proprietary) to post it. Good luck, it's a difficult thing to debug.

If there's any good news, it's that the more you work with threaded
code, the better you will get at preventing/finding/fixing bugs.



-- 
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me 
directly)

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

#90786

Le Fri, 22 Jul 2016 09:44:39 -0500,
Randy Howard <rhoward.mx@EverybodyUsesIt.com> écrivait :
> On 7/22/16 8:42 AM, JKB wrote:
>> 	I have tried gcc sanitizer (-fsanitize=address and thread). I have
>> 	found a minor error with -fsanitize=thread (but without any
>> 	consequence).
>
> Fair enough. It's not black magic, but it can be helpful. This is the
> main issue with threaded programming. It takes a lot of careful planning
> up front, or a LOT of painful debugging later on. Sometimes both. :-)
>
>> 	I suppose there is somewhere a bug in my code, but I'm not able to
>> 	find it. If pthread_exit() stops on internal mutex, I suppose that
>> 	pthread_t structure is corrupted. But I haven't found any memory or
>> 	heap corruption. It's a random bug and I have tried to find a race
>> 	condition without success.
>
> Well, I'm sure none of us can guess, and it's probably too large (or
> proprietary) to post it. Good luck, it's a difficult thing to debug.

	Large but GPL code.

> If there's any good news, it's that the more you work with threaded
> code, the better you will get at preventing/finding/fixing bugs.

	I use pthreads for a very long time. But I'm not able to solve this
	issue for several months :-(

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr

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

#90784

On 22/07/16 14:10, Randy Howard wrote:

<stuff>

Sorry (to all!) to go out-of-band, but I was too stupid to work out how 
to "replace the obvious text in the obvious way" to send you an email.

A while back, I mentioned a topic that you showed some interest in, that 
wasn't relevant to clc but /is/ relevant in comp.programming - up until 
now, I hadn't had time to get together something that was worth talking 
about, but now I (nearly) have, and I hope to post an article in c.p 
some time next week. Just a heads-up, really, in case you're still 
interested (the subject is stochastic music).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#90787

On Friday, July 22, 2016 at 8:10:43 AM UTC-5, Randy Howard wrote:
> I can't think of a single reason why anyone would prefer to use that
> ridiculous stuff in C11 for threading. pthreads is already there and
> well vetted.

It would be extremely helpful if there were standard ways by which
programs which didn't need threads, but did need to tell the compiler
that things might be accessed in ways it doesn't expect (e.g. DMA),
could give the compiler such information.  On a system with DMA, it
may be necessary to use some hardware-specific action to force a cache
flush prior to triggering a DMA operation, but since DMA is itself
hardware-specific, needing hardware-specific code to flush the cache
doesn't cause any loss of generality.  On the other hand, flushing the
hardware cache won't do any good if the compiler also has things cached
in registers.

On older compilers, given:

    int a,b,x,y;
    volatile int z;

    x=a; y=b;
    z=0;
    a=x; b=y;

the writes to x and y might occur in arbitrary order, and likewise the
reads of x and y, but all registers would be flushed prior to the write
of z.  GCC, however, does not seem to regard writes to volatile variables
as memory barriers, implying that in the absence of any other form of
memory barriers the only way to guarantee correct behavior would be to make
everything volatile (note that even something like:

    a = (volatile int*)&x;

might not suffice to ensure that gcc actually reads "x" after the write to
z, since gcc doesn't necessarily respect volatile qualifiers on pointers
if it can tell that the pointer identifies an object that isn't volatile-
qualified.

I would think that some of the C11 barriers, when supported, would be able
to provide the necessary guarantees, though it doesn't appear that the
Standard recognizes any category of implementations that support features
that can be handled entirely in the compiler versus ones that require OS
support.

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

#90793

On 07/22/2016 09:10 AM, Randy Howard wrote:
> On 7/20/16 12:42 PM, James R. Kuyper wrote:
>> On 07/20/2016 12:47 PM, JKB wrote:
>>>     Hello,
>>>
>>>     I'm debugging a huge program that can enter in deadlock on a
>>>     pthread_exit() syscall. I use gcc compiler on Linux or NetBSD.
> 
> clang has some pretty get sanitizers now (even if you prefer gcc most
> of the time for some bizarre reason, it's worth using the sanitizers,
> especially the threading one if your platform supports them. I'm
> pretty sure BSD does if not Linux.
> 
>>
>> As you yourself noted in your subject line, this is a POSIX-specific
>> question. As such, you're more likely to find people who can help you if
>> you post in a POSIX-specific forum, such as comp.unix.programmer.
> 
> Most of the formerly useful Usenet groups have become practically
> worthless, including the threads specific one which used to be quite
> active with real discussions about threading.

If the best available forum (note: usenet is not the entire world -
there's many other types of forums) for discussing POSIX programs has
nobody helpful that you can talk to, then POSIX must be dead. I doubt
that it's dead - most of the computers I've ever used in the past 40
years have been compatible with POSIX, and all of the computers I've
programmed for in the past 30 years have been POSIX compatible. I just
think you haven't found the right forum.
It certainly isn't this forum - otherwise the original question would
have produced a much larger number of more helpful responses.

>> C2011 added the new <threads.h> header, and a lot of features to support
>> multi-thread programs. If you were to re-writr this program to make use
>> of <threads.h> rather than <pthread.h>, then the corresponding question
>> about thrd_exit() could be asked here, in a reasonable expectation that
>> someone here might be able to answer it.
> 
> I can't think of a single reason why anyone would prefer to use that
> ridiculous stuff in C11 for threading. ... 

I was merely explaining what would have to be different to justify
posting a question like his in this forum. I was not endorsing or
recommending the use of <threads.h> - I don't have enough experience
with multi-threaded code to justify endorsing any particular way of
doing it.

> ... pthreads is already there and
> well vetted.

Well, that comment implicitly points out the most likely reason for
using C11 threads: when "pthreads is" NOT "already there". I've had
people point out that the "P" in POSIX stands for "Portable", as if
putting that P there made it portable. It isn't. POSIX is widespread,
but C is even more widely spread - it can be and has been implemented on
many platforms which do not support POSIX, many of which support
multi-threaded code by means that are incompatible with POSIX - but
which may still allow <threads.h> to be implemented as a thin wrapper
over native threading functions.

Obviously, code targeted only at POSIX platforms can safely rely upon
<pthreads.h>, and code targeted only at a set of non-POSIX platforms
that supports a different threading library can rely on that library.
However, if for any reason if you want your code to be portable to
systems with two or more different incompatible threading libraries,
then <threads.h> becomes a viable alternative to writing two or more
entirely different versions of your program. Of course, that only works
if all of the systems you're targeting support <threads.h>, and only if
<threads.h> provides all of the features that you'll need.

That might be an uncommon need, but I don't understand why you're so
sure that it's a non-existent need. Perhaps you feel that all the world
faces exactly the same problems you do, so if you've never needed
something like this, nobody needs it?

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

#90794

Randy Howard <rhoward.mx@EverybodyUsesIt.com> writes:
> On 7/20/16 12:42 PM, James R. Kuyper wrote:
[...]
>> C2011 added the new <threads.h> header, and a lot of features to support
>> multi-thread programs. If you were to re-writr this program to make use
>> of <threads.h> rather than <pthread.h>, then the corresponding question
>> about thrd_exit() could be asked here, in a reasonable expectation that
>> someone here might be able to answer it.
>
> I can't think of a single reason why anyone would prefer to use that
> ridiculous stuff in C11 for threading. pthreads is already there and
> well vetted.

I think the idea is that <threads.h> would be supported on
systems that don't have POSIX threads.  For example, it might be
implemented on top of Windows threads in a Windows implementation.
(There seems to be *some* support for POSIX threads on Windows, but
using an interface defined by the C standard would IMHO be better.)

Support for C11 <threads.h> seems to be rather slow in appearing,
so we'll see when and whether that goal is met.

Threading is an optional feature, so conforming C11 implementations are
not required to support it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#90829

On 07/23/16 05:28 AM, Keith Thompson wrote:
> Randy Howard <rhoward.mx@EverybodyUsesIt.com> writes:
>> On 7/20/16 12:42 PM, James R. Kuyper wrote:
> [...]
>>> C2011 added the new <threads.h> header, and a lot of features to support
>>> multi-thread programs. If you were to re-writr this program to make use
>>> of <threads.h> rather than <pthread.h>, then the corresponding question
>>> about thrd_exit() could be asked here, in a reasonable expectation that
>>> someone here might be able to answer it.
>>
>> I can't think of a single reason why anyone would prefer to use that
>> ridiculous stuff in C11 for threading. pthreads is already there and
>> well vetted.
>
> I think the idea is that <threads.h> would be supported on
> systems that don't have POSIX threads.  For example, it might be
> implemented on top of Windows threads in a Windows implementation.
> (There seems to be *some* support for POSIX threads on Windows, but
> using an interface defined by the C standard would IMHO be better.)
>
> Support for C11 <threads.h> seems to be rather slow in appearing,
> so we'll see when and whether that goal is met.

That is surprising.  The C++ version is pretty much universally 
available and well used.

-- 
Ian

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

#90881

On 7/22/16 12:28 PM, Keith Thompson wrote:
> Randy Howard <rhoward.mx@EverybodyUsesIt.com> writes:
>> On 7/20/16 12:42 PM, James R. Kuyper wrote:
> [...]
>>> C2011 added the new <threads.h> header, and a lot of features to support
>>> multi-thread programs. If you were to re-writr this program to make use
>>> of <threads.h> rather than <pthread.h>, then the corresponding question
>>> about thrd_exit() could be asked here, in a reasonable expectation that
>>> someone here might be able to answer it.
>>
>> I can't think of a single reason why anyone would prefer to use that
>> ridiculous stuff in C11 for threading. pthreads is already there and
>> well vetted.
>
> I think the idea is that <threads.h> would be supported on
> systems that don't have POSIX threads.  For example, it might be
> implemented on top of Windows threads in a Windows implementation.
> (There seems to be *some* support for POSIX threads on Windows, but
> using an interface defined by the C standard would IMHO be better.)

I first started using pthreads on Windows in the late 90s. It's not 
supported directly by microsoft but neither is C11, or even C99.

It works quite well. Nuff said.




-- 
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me 
directly)

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

#90886

On 07/23/2016 05:43 PM, Randy Howard wrote:
> On 7/22/16 12:28 PM, Keith Thompson wrote:
>> Randy Howard <rhoward.mx@EverybodyUsesIt.com> writes:
>>> On 7/20/16 12:42 PM, James R. Kuyper wrote:
>> [...]
>>>> C2011 added the new <threads.h> header, and a lot of features to support
>>>> multi-thread programs. If you were to re-writr this program to make use
>>>> of <threads.h> rather than <pthread.h>, then the corresponding question
>>>> about thrd_exit() could be asked here, in a reasonable expectation that
>>>> someone here might be able to answer it.
>>>
>>> I can't think of a single reason why anyone would prefer to use that
>>> ridiculous stuff in C11 for threading. pthreads is already there and
>>> well vetted.
>>
>> I think the idea is that <threads.h> would be supported on
>> systems that don't have POSIX threads.  For example, it might be
>> implemented on top of Windows threads in a Windows implementation.
>> (There seems to be *some* support for POSIX threads on Windows, but
>> using an interface defined by the C standard would IMHO be better.)
>
> I first started using pthreads on Windows in the late 90s. It's not
> supported directly by microsoft but neither is C11, or even C99.
>
> It works quite well. Nuff said.

It works well for you - in your particular situation, which does not 
justify dismissing as irrelevant alternatives that might make more sense 
to someone working in a very different situation. All that's needed is 
someone who needs to port their code to two or more groups of platforms, 
all of which have C2011 available, but at least one of which does not 
support POSIX. Can you justify implying that no one is in this position, 
and that no one ever will be?

The last time I heard expert opinion on the matter, I was told that 
there is a POSIX subsystem for Windows, which implements many (but not 
all) of the features required to conform fully to POSIX, and that use of 
this sub-system is incompatible with full use of all Win32 features. 
Other people claimed that those experts were talking nonsense, with the 
implication that there is an implementation of pthreads that both fully 
conforms to POSIX and is fully compatible with all features of Win32 - 
except, they never actually said so, they just implied it, and never 
answered detailed questions about those implications.

I investigated as far as could on my own, which wasn't very far, since I 
am not a Windows expert, nor do I have any Windows machine I could test 
things on. I found a Microsoft web site which listed dozens of pthreads 
functions that it freely admitted were both required by POSIX, and not 
implemented in the POSIX subsystem for Windows, which would favor the 
statements of the first group I mentioned. However, I couldn't find any 
clear statements about the simultaneous use of the POSIX subsystem and 
Win32. That's not because my searches didn't turn up anything - it was 
because my searches turned up too much information, and I couldn't sift 
through it to find the particular information I was looking for.

You sound like someone familiar with the relevant issues, can you 
discuss them?

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

#90887

"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 07/23/2016 05:43 PM, Randy Howard wrote:
[...]
>> I first started using pthreads on Windows in the late 90s. It's not
>> supported directly by microsoft but neither is C11, or even C99.
>>
>> It works quite well. Nuff said.
>
> It works well for you - in your particular situation, which does not 
> justify dismissing as irrelevant alternatives that might make more sense 
> to someone working in a very different situation. All that's needed is 
> someone who needs to port their code to two or more groups of platforms, 
> all of which have C2011 available, but at least one of which does not 
> support POSIX. Can you justify implying that no one is in this position, 
> and that no one ever will be?

I tend to agree -- but it's complicated by the fact that C11 thread
support is an optional feature.  I'm disappointed by the lack of support
in glibc.  (My disappointment is of course tempered by the fact that
glibc is free and I haven't contributed to the work of implementing it.)

I've seen third-party libraries that at least attempt to support C11
threads, probably on top of pthreads.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#90894

On 07/23/2016 06:17 PM, James R. Kuyper wrote:
...
> It works well for you - in your particular situation, which does not 
> justify dismissing as irrelevant alternatives that might make more sense 
> to someone working in a very different situation. All that's needed is 
> someone who needs to port their code to two or more groups of platforms, 
> all of which have C2011 available, but at least one of which does not 
> support POSIX. Can you justify implying that no one is in this position, 
> and that no one ever will be?

As Keith has pointed out, it's not sufficient that C2011 be available -
it must be an implementation of C2011 that implements the optional
<threads.h>.

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

#91052

On 7/24/16 6:27 AM, James Kuyper wrote:
> On 07/23/2016 06:17 PM, James R. Kuyper wrote:
> ....
>> It works well for you - in your particular situation, which does not
>> justify dismissing as irrelevant alternatives that might make more sense
>> to someone working in a very different situation. All that's needed is
>> someone who needs to port their code to two or more groups of platforms,
>> all of which have C2011 available, but at least one of which does not
>> support POSIX. Can you justify implying that no one is in this position,
>> and that no one ever will be?
>
> As Keith has pointed out, it's not sufficient that C2011 be available -
> it must be an implementation of C2011 that implements the optional
> <threads.h>.

Indeed.  Meanwhile, pthread support is available on Windows, Linux, BSD,
OS X, Novell NetWare (I kid you not), AIX, Solaris, HP-UX, a number of
other UNIX platforms, I've even heard rumor that it is at least
partially supported on Android.

Meanwhile C11 thread support?  Mostly crickets. Your question would be
a lot more interesting if the chances of "two or more groups of
platforms, all of which have C2011 available" not being an empty set
wasn't so high.

Gcc?  Not implemented.
clang? Not implemented.
MSVC? Not implemented.

Need I go on?


-- 
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me 
directly)

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

#91053

On 07/26/16 08:22 AM, Randy Howard wrote:
>
> Indeed.  Meanwhile, pthread support is available on Windows, Linux, BSD,
> OS X, Novell NetWare (I kid you not), AIX, Solaris, HP-UX, a number of
> other UNIX platforms, I've even heard rumor that it is at least
> partially supported on Android.
>
> Meanwhile C11 thread support?  Mostly crickets. Your question would be
> a lot more interesting if the chances of "two or more groups of
> platforms, all of which have C2011 available" not being an empty set
> wasn't so high.
>
> Gcc?  Not implemented.
> clang? Not implemented.
> MSVC? Not implemented.

While all three support C++11 threading...

-- 
Ian

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

#91055

On 07/25/2016 04:22 PM, Randy Howard wrote:
...
> Indeed.  Meanwhile, pthread support is available on Windows,

I asked you a question about POSIX and Windows on 2016-07-23, which you 
never answered. The above comment reinforces my suspicion that you 
should be able to answer it. Can you?

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web