Home > Archive > Unix Programming > August 2005 > phreads and processes
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
phreads and processes
|
|
|
| I have a program that uses pthreads. I now need to run it in multiple
processes also.
I guess the question would be if I have added shared memory and SysV
semaphores, do I still require the pthread mutexes and events; i.e. do
pthreads honor the SysV semaphores or can I substitute the semaphores for
the pthread mutexes and events?
It still needs to be multi-threaded.
Thanks,
| |
| Pascal Bourguignon 2005-08-17, 9:14 am |
| "Jim" <j1mw_no_spam_plz@bellsouth.net> writes:
> I have a program that uses pthreads. I now need to run it in multiple
> processes also.
> I guess the question would be if I have added shared memory and SysV
> semaphores, do I still require the pthread mutexes and events; i.e. do
> pthreads honor the SysV semaphores or can I substitute the semaphores for
> the pthread mutexes and events?
>
> It still needs to be multi-threaded.
AFAIK, semaphores are pthread-safe: you can use only semaphores (or
other SysV IPC to synchronize both threads and processes.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
| |
| Maxim Yegorushkin 2005-08-17, 9:14 am |
| Jim wrote:
> I have a program that uses pthreads. I now need to run it in multiple
> processes also.
> I guess the question would be if I have added shared memory and SysV
> semaphores, do I still require the pthread mutexes and events;
You may use semaphores and mutexes and events if you need to. Also you
can share mutexes between processes using shared memory.
> i.e. do pthreads honor the SysV semaphores
pthreads doesn't care.
> can I substitute the semaphores for
> the pthread mutexes and events?
You can.
| |
|
| Ahh... so, I could conceivably write a pthreaded pgm and use semaphores
instead of mutexes, if I wanted to.
Yes?
An idea also arises how to get around the abcence of semtimedop also - could
put the pthread cond.variable and mutexes in shared memory and have a thread
in process A trigger the cond. variable in shared memory that wakes up
process B from it's pthread_cond_timedwait().
"Maxim Yegorushkin" <maxim.yegorushkin@gmail.com> wrote in message
news:1124287263.215071.157520@f14g2000cwb.googlegroups.com...
> Jim wrote:
>
> You may use semaphores and mutexes and events if you need to. Also you
> can share mutexes between processes using shared memory.
>
>
> pthreads doesn't care.
>
>
> You can.
>
| |
| Maxim Yegorushkin 2005-08-18, 4:03 am |
| Jim wrote:
> Ahh... so, I could conceivably write a pthreaded pgm and use semaphores
> instead of mutexes, if I wanted to.
> Yes?
That's right. Note that David R. Butenhof in his book states that
semaphores are comparatively more expensive than mutexes, since they
are kernel objects and their number is limited. And also that when
using pthreads there is usually no need to use semaphores, unless you
want to send notifications from signal handlers, since sem_post() is
async signal safe, while pthread_cond_signal() family functions are
not.
> An idea also arises how to get around the abcence of semtimedop also - could
> put the pthread cond.variable and mutexes in shared memory and have a thread
> in process A trigger the cond. variable in shared memory that wakes up
> process B from it's pthread_cond_timedwait().
Yes, you may put a mutex and a condition variable in shared memory
using pthread_mutexattr_setpshared() and pthread_condattr_setpshared()
and use pthread_cond_timedwait() and pthread_cond_signal() from
different processes.
| |
|
| It appears that in a single process, if two pthreads ask for the same shared
memory with the same key, the first thread (main) gets the memory, and the
2nd pthread gets the same memory.
Each thread uses "shmget( key, len, 0660 );", and if that fails, uses *shmid
= shmget( key, len, 0660 | IPC_CREAT );
In both threads, key and len are identical. ipcs shows ony a single shmem
segment of the correct size and 2 attaches..
Is this expected behavior - whereby only a single thread in any given
process is allowed to attach shared memory? Or is the behavior merely
"undefined"?
Thanks,
"Maxim Yegorushkin" <maxim.yegorushkin@gmail.com> wrote in message
news:1124354550.550153.277300@f14g2000cwb.googlegroups.com...
> Jim wrote:
>
> That's right. Note that David R. Butenhof in his book states that
> semaphores are comparatively more expensive than mutexes, since they
> are kernel objects and their number is limited. And also that when
> using pthreads there is usually no need to use semaphores, unless you
> want to send notifications from signal handlers, since sem_post() is
> async signal safe, while pthread_cond_signal() family functions are
> not.
>
could[color=darkred]
thread[color=darkred]
>
> Yes, you may put a mutex and a condition variable in shared memory
> using pthread_mutexattr_setpshared() and pthread_condattr_setpshared()
> and use pthread_cond_timedwait() and pthread_cond_signal() from
> different processes.
>
| |
|
| Oops, meant to say that the 2nd pthread gets a different memory address.
"Jim" <j1mw_no_spam_plz@bellsouth.net> wrote in message
news:_tmNe.26779$XM3.24198@bignews5.bellsouth.net...
> It appears that in a single process, if two pthreads ask for the same
> shared
> memory with the same key, the first thread (main) gets the memory, and the
> 2nd pthread gets the same memory.
> Each thread uses "shmget( key, len, 0660 );", and if that fails, uses
> *shmid
> = shmget( key, len, 0660 | IPC_CREAT );
> In both threads, key and len are identical. ipcs shows ony a single shmem
> segment of the correct size and 2 attaches..
>
> Is this expected behavior - whereby only a single thread in any given
> process is allowed to attach shared memory? Or is the behavior merely
> "undefined"?
>
> Thanks,
>
> "Maxim Yegorushkin" <maxim.yegorushkin@gmail.com> wrote in message
> news:1124354550.550153.277300@f14g2000cwb.googlegroups.com...
> could
> thread
>
>
| |
| David Schwartz 2005-08-19, 6:56 pm |
|
"mail" <j1mw_no_spam_plz@bellsouth.net> wrote in message
news:NZmNe.175$ZD4.59@bignews3.bellsouth.net...
> Oops, meant to say that the 2nd pthread gets a different memory address.
What would the alternative be?
DS
| |
|
| It got the same shmid so I thought it would get the same address, esp since
the ipcs showed only the single shmid and key. Live and learn.
BTW, I realized quickly that no need to even do it in a 2nd thread in the
same process - just found it curious.
"David Schwartz" <davids@webmaster.com> wrote in message
news:de5kgj$ba0$1@nntp.webmaster.com...
>
> "mail" <j1mw_no_spam_plz@bellsouth.net> wrote in message
> news:NZmNe.175$ZD4.59@bignews3.bellsouth.net...
>
>
> What would the alternative be?
>
> DS
>
>
| |
| David Schwartz 2005-08-20, 2:56 am |
|
"Jim" <j1mw_no_spam_plz@bellsouth.net> wrote in message
news:stuNe.16581$xW.10450@bignews6.bellsouth.net...
> It got the same shmid so I thought it would get the same address, esp
> since
> the ipcs showed only the single shmid and key. Live and learn.
> BTW, I realized quickly that no need to even do it in a 2nd thread in the
> same process - just found it curious.
If they got the same address, what would happen if one thread decided to
make the memory read-only while another thread made it write-only? Think
about what should happen if the same thread accesses it twice. Imagine a
program that's using some shared memory segment that calls a library
function that does so too.
DS
|
|
|
|
|