7cc
Subj : Re: signaling threads from a forked child?
To   : comp.programming.threads
From : markh@compro.net
Date : Fri Aug 05 2005 06:22 am

It looks like pthread_mutexattr_setpshared nor PTHREAD_PROCESS_SHARED
are available for Linux. Yes I've found sample code that does this but
I can't use this method in Linux apparently. I had already moved all my
mutex's and codvars into a SHM thinking it would help.  Or at least I
think they now reside physically in the SHM. I'll have to go back and
verify that part I guess.

The **REASON** my threads need to wait: This already icsisting
application is an emulation of a legacy RT computer. The main process
is the lecacy CPU. Each thread is an I/O controller. One thread for
each device. Be it a disk, tape, terminal, etc... When these I/O
threads are not required to work they must not use any cpu time. When
the CPU executes a legacy instruction, to say read from the disk, he
sets up info relating to the I/O then signals the thread to go do it,
then continues on executing more instructions.  This legacy computer
has an SMP option (max 2 processors) .  I  fork this guy from the CPU
process. This Second CPU was never allowed to do I/O or deal with
interrupts at all. He was purely computational. However, I now want to
enable him to do I/O using the same threads that the CPU process uses.
The CPU and I/O  threads use pthread_cond_wait and pthread_cond_signal.
 Each of the threads mutex/condvar and other device info are kept in
dedicated device structures that reside in a SHM. This is already code
that is working and if I have to make any major change it, it looks
like the easiest way would be to make the forked secondary CPU process
a thread also.

So, if there is no support for the proces shared attribute in Linux
NTPL I will NOT be able to use pthread_cond_signal/pthread_cond_wait
from my forked process. Correct?

I assume that I "CAN" use this method across threads. No???

Thanks
Mark

.

0