threads

threads

Post by Pirabhu Rama » Sat, 10 May 2003 00:17:52



Hi,

Is it possible for just a single thread to fail in a Multi-threaded
application? ( including cases where threads are created as light-weight
processes)
If so, how do I detect the failure of that thread from any other thread.
Assume no join is performed on the threads.

Thanks in advance
Pirabhu

ps: Did a brief search in FAQ but couldn't find similar questions. Please
point out the relevant link if similar question was already posted.

----------------------------------------------------------------
Hope is a dangerous thing. Hope can drive a man insane.

 
 
 

threads

Post by Marc Rochkin » Sat, 10 May 2003 02:14:06



Quote:> Hi,

> Is it possible for just a single thread to fail in a Multi-threaded
> application? ( including cases where threads are created as light-weight
> processes)
> If so, how do I detect the failure of that thread from any other thread.
> Assume no join is performed on the threads.

Maybe others know what you mean, but for me, could you define "fail?"

--Marc

 
 
 

threads

Post by Pirabhu Rama » Sat, 10 May 2003 02:20:43





> > Hi,

> > Is it possible for just a single thread to fail in a Multi-threaded
> > application? ( including cases where threads are created as light-weight
> > processes)
> > If so, how do I detect the failure of that thread from any other thread.
> > Assume no join is performed on the threads.

> Maybe others know what you mean, but for me, could you define "fail?"

> --Marc

By fail I meant the death of the thread. eg in linux every thread is given a
separate PID. What if one of the thread alone dies? (Is it possible?) Will I
get any signal (like in fork we get a SIGCHLD)
 
 
 

threads

Post by Grant Taylo » Sat, 10 May 2003 02:54:50



> By fail I meant the death of the thread. eg in linux every thread is
> given a separate PID. What if one of the thread alone dies? (Is it
> possible?) Will I get any signal (like in fork we get a SIGCHLD)

On Linux, yes; with LinuxThreads each thread is merely a process which
shares 100% of it's memory map with other processes.  Signal behavior
follows exactly as the model implies.

I've never used sigchld in a threaded app on Linux, but I have written
a sampling profiler using SIGPROF which profiled just one specific
thread.  Linux's model made this completely trivial.  Other things
become more awkward...

--
Grant Taylor - gtaylor<at>picante.com - http://www.picante.com/~gtaylor/
 Linux Printing Website and HOWTO:  http://www.linuxprinting.org/

 
 
 

threads

Post by David Schwart » Sat, 10 May 2003 06:31:33



Quote:> By fail I meant the death of the thread. eg in linux every thread is given
a
> separate PID. What if one of the thread alone dies? (Is it possible?) Will
I
> get any signal (like in fork we get a SIGCHLD)

    Dies how? You're still not explaining what you mean. Give an example of
how or why a thread could die.

    DS

 
 
 

threads

Post by Marc Rochkin » Sat, 10 May 2003 06:46:08


There may be a basic misunderstanding on the part of the OP as to how a
POSIX thread can be terminated. It can be cancelled or it can exit.

A thread can't be terminated by a signal, even if the signal is directed to
the thread and not to the process. Any such signal would terminate the
entire process.

--Marc

 
 
 

threads

Post by Pirabhu Rama » Sat, 10 May 2003 06:59:45


Quote:> There may be a basic misunderstanding on the part of the OP as to how a
> POSIX thread can be terminated. It can be cancelled or it can exit.

> A thread can't be terminated by a signal, even if the signal is directed
to
> the thread and not to the process. Any such signal would terminate the
> entire process.

Yes I know that signals are delivered to all the threads and the scheduler
will select the particular thread, if the thread has not blocked the signal.
There a few cases which I want to clarify
1) Are there any extreme cases like single event upsets or some Byzantine
cases where only one thread can fail?
2)If a maskable signal such as SIGINT is delivered to the process and all
but one thread blocks the signal what is the behavior? Does the whole
process get killed even though the other threads blocked the signal?

Thanks in advance

 
 
 

threads

Post by Marc Rochkin » Sat, 10 May 2003 07:14:22



Quote:> > There may be a basic misunderstanding on the part of the OP as to how a
> > POSIX thread can be terminated. It can be cancelled or it can exit.

> > A thread can't be terminated by a signal, even if the signal is directed
> to
> > the thread and not to the process. Any such signal would terminate the
> > entire process.

> Yes I know that signals are delivered to all the threads and the scheduler
> will select the particular thread, if the thread has not blocked the
signal.
> There a few cases which I want to clarify
> 1) Are there any extreme cases like single event upsets or some Byzantine
> cases where only one thread can fail?

I would say that there are no such cases in the standard, but a defective
implementation is free to do anything it likes. I don't think this needs to
be programmed for.

Quote:> 2)If a maskable signal such as SIGINT is delivered to the process and all
> but one thread blocks the signal what is the behavior? Does the whole
> process get killed even though the other threads blocked the signal?

Yes. The specification doesn't allow terminate, stop, continue, or ignore to
affect only one thread. Actually, ALL actions are for the process as a
whole. There is no pthread_sigaction function, and sigaction takes no
thread-ID argument.

The only reason why a caught signal appears to affect only one thread is
just that it gets caught only once (per occurrence), and the handler has to
execute someplace.

--Marc

 
 
 

threads

Post by David Schwart » Sat, 10 May 2003 07:15:44



Quote:> 1) Are there any extreme cases like single event upsets or some Byzantine
> cases where only one thread can fail?

    You're asking *us* what *you* mean by "fail". We have no idea.

Quote:> 2)If a maskable signal such as SIGINT is delivered to the process and all
> but one thread blocks the signal what is the behavior? Does the whole
> process get killed even though the other threads blocked the signal?

    If the default behavior of SIGINT is to kill the process and a thread
that has not blocked SIGINT gets a SIGINT, then the process is supposed to
be killed.

    DS

 
 
 

threads

Post by Alexander Terekho » Sat, 10 May 2003 18:11:43


[...]

Quote:> On Linux, yes; with LinuxThreads each thread is merely a process which
> shares 100% of it's memory map with other processes.  Signal behavior
> follows exactly as the model implies.

http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/release-notes/x86

"....
 Red Hat Linux 9 includes the Native POSIX Thread Library (NPTL), a
 new implementation of POSIX threads for Linux. This library provides
 performance improvements and increased scalability for i686 or better
 processors.

 This thread library is designed to be binary compatible with the old
 LinuxThreads implementation; however, applications that rely on the
 places where the LinuxThreads implementation deviates from the
 POSIX standard will need to be fixed. Notable differences include:

 - Signal handling has changed from per-thread signal handling to
   POSIX process signal handling.

 - getpid() returns the same value in all threads.

 ...."

regards,
alexander.

 
 
 

threads

Post by Marc Rochkin » Sat, 10 May 2003 22:37:06


[snip]

Quote:>  new implementation of POSIX threads for Linux.

[snip]

Quote:>  - Signal handling has changed from per-thread signal handling to
>    POSIX process signal handling.

>  - getpid() returns the same value in all threads.

Which means it is NOT an implementation of POSIX Threads! ("Almost" and
"not" are usually interchangeable words.)

--Marc

 
 
 

threads

Post by g.. » Sat, 10 May 2003 22:50:27




Quote:> [snip]

>>  new implementation of POSIX threads for Linux.

> [snip]

>>  - Signal handling has changed from per-thread signal handling to
>>    POSIX process signal handling.

>>  - getpid() returns the same value in all threads.

> Which means it is NOT an implementation of POSIX Threads! ("Almost" and
> "not" are usually interchangeable words.)

well, as I can see neither "almost" or "not" in the above text, you
appear to talking rubbish.

-tony

 
 
 

threads

Post by Alexander Terekho » Sat, 10 May 2003 23:14:26



> [snip]

> >  new implementation of POSIX threads for Linux.

> [snip]

> >  - Signal handling has changed from per-thread signal handling to
> >    POSIX process signal handling.

> >  - getpid() returns the same value in all threads.

> Which means it is NOT an implementation of POSIX Threads! ("Almost" and
> "not" are usually interchangeable words.)

C'mon, "NPTL's" getpid() returns the process ID of the calling POSIX
process -- the same value in all its threads.

regards,
alexander.

 
 
 

threads

Post by Marc Rochkin » Sat, 10 May 2003 23:26:42




> > [snip]

> > >  new implementation of POSIX threads for Linux.

> > [snip]

> > >  - Signal handling has changed from per-thread signal handling to
> > >    POSIX process signal handling.

> > >  - getpid() returns the same value in all threads.

> > Which means it is NOT an implementation of POSIX Threads! ("Almost" and
> > "not" are usually interchangeable words.)

> C'mon, "NPTL's" getpid() returns the process ID of the calling POSIX
> process -- the same value in all its threads.

> regards,
> alexander.

Right... misread the "changed from per-thread" part of the post. If it now
conforms, this is terrific!

--Marc

 
 
 

threads

Post by Valentin Nechaye » Sat, 10 May 2003 23:49:42



>>  new implementation of POSIX threads for Linux.
MR> [snip]
>>  - Signal handling has changed from per-thread signal handling to
>>    POSIX process signal handling.

>>  - getpid() returns the same value in all threads.

MR> Which means it is NOT an implementation of POSIX Threads!

Why?

-netch-

 
 
 

1. Threads, threads, threads

Well, I solved some of my problems with X11R6 & Solaris 2 threads, having
belatedly discovering XInitThreads() & the related lock/unlock functions.
However I still cannot get XNextEvent() to work correctly. I have 2 threads,
one blocks on a semaphore & the other on XNextEvent(). When the data
thread is done the XNextEvent() thread should kick in if an event is
waiting, but it doesn't do so consistently. I've been reduced to spinning
on XPending(), which largely defeats the purpose of the multithreading. Is
there a reason that XNextEvent() isn't thread safe? From what I can make
out from the source it will ultimately use either select() or poll() to
block & both are supposed to be thread safe in Solaris 2.

A second problem seems to be that thr_yield() doesn't seem to actually do
anything. If the data thread yields when done the XNextEvent() (or the
kludged XPending()) thread doesn't get the processor, even when it is at a
higher priority. I'm reduced to suspending the data thread so that the
other can check for user input & then restart it if there is none. What
could be happening that prevents the yield from allowing the other thread
to start?

--

National Center For Atmospheric Research        lokkar borni under sole-vegg
Box 3000 Boulder, CO 80307-3000                 Gj?'i med sitt shinn
303-497-2057                                    jagar borni inn.

2. Console log-in problem

3. Threads in linux versus threads in NT and threads in Solaris.

4. Multi-part downloads

5. dvd compat?

6. threads packages: kernel threads vs. user threads

7. Help!!! LILO crashes...

8. POSIX threads, thread-specific data: what about the "main" thread?

9. does linux JDK 1.1.x use posix threads (pthreads) or green threads?

10. Differences between Solaris threads and POSIX threads

11. HELP: communication interface between kernel thread and user thread.

12. HELP: Linux thread inside a thread ...