Communication between threads of same PIDs

I suppose you are talking about signals. Here I know close to nothing about, but the pthread library seems to provide means for signal handler per thread thread.

OTOH, when using System 5 message queues, I suppose you don't need to bother with the PID at all.

-Michael

The PIDs are not the same. Each thread gets its own PID.

Kind regards,

Iwo

Get a book on POSIX IPC. Also, Google is your friend.

No, they're different.

In general, it's better for everyone if you actually try stuff out before asking questions. You're likely to get a much better response.

Hi, Thx for your valuable replies. I Got the correct correlation. The communication is possible between threads / processes. And yes, the PIDs are different.

Consider that i have 3 threads of a process. But how to kill a thread alone ?

I find that there is a way to kill the process. But how to kill a specific thread.

I did search the google, i find things w.r.t processes w.r.t kill and i donot find w.r.t thread.

Regards, Karthik Balaguru

IMHO the only decent way is using the pthread library. Supposedly here the thread is required to end itself. IMHO a program that fails to care that all of it's threads always can properly finish is considered to be broke and can killed completely.

-Michael

If you have written the threads yourself, why on earth would you want to kill some of these. Just insert some logic into that thread and perform a controlled exit on that thread when the right conditions occur.

Paul

Given a PID is there a mechanism to identify that it is for a thread or a process ?

-Vikram

Ger> > Hi,

Three hints:

1) Your problem is probably not an implementation issue. Usually you have to solve such issues in the design area, and would end up with much less complexity in the implementation. Complex implementation issues tend to demonstrate poor design quality.

2) Often, you don't need any real communication between threads. I define communication like in a phone call, where information flows in both directions and one information depends on the other. Usually, you are done with some means to share variable contents. This can be done much easier. Global variables, Condition variables (see

etc. provide means for this sort of "off-line" communication.

Always be aware that real communication requires one thread to "wait" until the other provides the information, or to poll an input channel. This is often undesirable, because it reduces the productivity.

3) Draw a graphical representation of the threads and the communication. Threads are a good means, if you can organize data flows in vertical direction (up-down-up). Horizontal data flows between threads (left-right) might show a poor design. Maybe a reorganization of the threads would make things easier and would probably remove the need for communication. Reorganization might result in:

- combine the two threads, if only they have to communicate.

- isolate the both parts which have to communicate and pack them together in a new thread. Hopefully none of them would require any communication any more.

- pack smaller packets and leave the coordination to the calling thread (there's no reason to have only 3 threads instead of 15...).

Bernhard

Not that I know of, other than running ps and checking if the PPID has the same name.

Assuming a 2.6 kernel...

man 3 gettid man 3 getpid

if pid == tid there is no thread group. otherwise each thread will have a unique tid and a common pid.

Hi all, Thx for your replies. There was some design flaw. It has been fixed now.

Got some good info : (similar things has been suggested by you people. Thx )

Threads can terminate themselves by either returning from their entry-point routine or calling a library subroutine. Threads can also terminate other threads, using a mechanism called cancellation. Any thread can request the cancellation of another thread. Each thread controls whether it may be canceled or not. Cleanup handlers may also be registered to perform operations when a cancellation request is acted upon

visit :

->

Good link.

Thx, Karthik Balaguru

Each PID is 32bits, wrapping (modulus) at 30000 for really old software. If CLONE_PID is not used, each thread will get its own PID like any other process. However, if the PID is to be shared, the kernel uses the upper 16bits to assign the thread ID (TID) [please note that this is probably not in the 2.0.* kernel version; we'll see it in 2.1.* for sure.]

Furthermore, each process has at least one thread (the parent). Each new thread will be assigned a TID beginning with 1. A TID of 0 (e.g.

0x0000FFFF mask) will address all threads within a process. Suppose an app has three threads (parent and two task managers) and the threads share the parent's PID. Suppose, the PIDs for each might be 0x00011234 (parent), 0x00021234 (child thread #1) and 0x00031234 (child thread #2). Each thread can be accessed or signaled individually -or- the whole task could be addressed with 0x00001234 (note that the first four digits are zero masking the TIDs).

It is the intent that the long format will work with existing apps. And, older apps that signal the whole task will still work (by accessing the whole task at once). However a shorthand has been proposed: PID.TID (e.g. 46.2 would be the second thread of PID 46).

Thx, Karthik Balaguru

You speak of Kernel as of 2.1.

Is all this true for NTPL (kernel 2.6), too ?

-Michael

Threads terminate by explicitly calling pthread_exit, by letting the function return, or by a call to the function exit which will terminate the process including any threads.

void pthread_exit(void *retval); // Arguments: retval - Return value of thread.

This routine kills the thread. The pthread_exit function never returns. If the thread is not detached, the thread id and return value may be examined from another thread by using pthread_join. Note: the return pointer *retval, must not be of local scope otherwise it would cease to exist once the thread terminates.

Thx, Karthik Balaguru

Sorry, but my question was if the highword/loword notation holds for Kernel 2.6 NPTL as well.

Thanks,

-Michael

I think it has supports. Need to check it out.

Got an interesting thing via mail. The pid is 16 bits. A 16-bit tid can fit in the top bits to create a 32-bit global thread identifier. Users can use pid.tid to identify a particular thread, or just the pid to mean everything. Number the threads from one and let zero mean "all threads" so that the old software works. Then you can do the following method of Kill : "kill -9 1234" for the whole process "kill -9 1234.12" for just thread 12.

kill -9 1234 # normal, all threads or the single thread kill -9 1234.0 # means the same as above kill -9 1234.12 # new, just thread 12 please

Regards, Karthik Balaguru

And this supposedly will do the API call with the PID parameter set to

0x000c04D2 ( = 1234 + 12