sharing Pthread mutexes among processes

sharing Pthread mutexes among processes

Post by Marko Asplun » Tue, 12 Jun 2001 22:55:03



i'm writing an application which uses Pthread mutexes for
synchronizing among a group of processes. i've understood
that mutexes can be created in shared memory and then
set as shared. i'm trying do the following on RedHat v6.2
(glibc-2.1.3-22):

pthread_mutexattr_setpshared(&mutex_attr, PTHREAD_PROCESS_SHARED);

this function does not exist in glibc on my system, however.
how do i set the mutex as "shared" on this system?

best regards,
--
        aspa

 
 
 

sharing Pthread mutexes among processes

Post by Adam Finema » Tue, 12 Jun 2001 22:43:06



> i'm writing an application which uses Pthread mutexes for
> synchronizing among a group of processes. i've understood
> that mutexes can be created in shared memory and then
> set as shared. i'm trying do the following on RedHat v6.2
> (glibc-2.1.3-22):

> pthread_mutexattr_setpshared(&mutex_attr, PTHREAD_PROCESS_SHARED);

> this function does not exist in glibc on my system, however.
> how do i set the mutex as "shared" on this system?

> best regards,
> --
>         aspa

That function is not implemented linux pthreads, so the pshared
attribute is not supported.  Are you absolutedly sure that it's
necessary?  What are you trying to do?

--
Adam

 
 
 

sharing Pthread mutexes among processes

Post by Daniel Barro » Wed, 13 Jun 2001 04:49:34




Quote:

> i'm writing an application which uses Pthread mutexes for
> synchronizing among a group of processes. i've understood

Do you mean processes, or threads?

[snip]

--
Daniel Barron - use [at jadeb.com] for personal replys.

 
 
 

sharing Pthread mutexes among processes

Post by Ken Whale » Wed, 13 Jun 2001 08:51:45


pthreads-the-standard specifices PTHREAD_PROCESS_SHARED
(as an option?), but linuxthreads-the-implementation currently does
not support PTHREAD_PROCESS_SHARED.


Quote:

> i'm writing an application which uses Pthread mutexes for
> synchronizing among a group of processes. i've understood
> that mutexes can be created in shared memory and then
> set as shared. i'm trying do the following on RedHat v6.2
> (glibc-2.1.3-22):

> pthread_mutexattr_setpshared(&mutex_attr, PTHREAD_PROCESS_SHARED);

> this function does not exist in glibc on my system, however.
> how do i set the mutex as "shared" on this system?

> best regards,
> --
> aspa

 
 
 

sharing Pthread mutexes among processes

Post by Marko Asplun » Wed, 13 Jun 2001 21:26:57





> > i'm writing an application which uses Pthread mutexes for
> > synchronizing among a group of processes. i've understood

> Do you mean processes, or threads?

i mean processes. i want to use pthread mutexes for inter-process
synchronization by creating the mutexes in a shared memory segment.

--
        aspa

 
 
 

sharing Pthread mutexes among processes

Post by Marko Asplun » Wed, 13 Jun 2001 21:34:34




> > i'm writing an application which uses Pthread mutexes for
> > synchronizing among a group of processes. i've understood
> > that mutexes can be created in shared memory and then
> > set as shared. i'm trying do the following on RedHat v6.2
> > (glibc-2.1.3-22):

> > pthread_mutexattr_setpshared(&mutex_attr, PTHREAD_PROCESS_SHARED);

> > this function does not exist in glibc on my system, however.
> > how do i set the mutex as "shared" on this system?

> That function is not implemented linux pthreads, so the pshared
> attribute is not supported.  Are you absolutedly sure that it's
> necessary?  What are you trying to do?

do you know if this feature will be supported by linux pthreads?

i'm trying to implement inter-process locks using pthread mutexes
as in Stevens Unix network programming vol 1, 2e. i've already
done this using semaphores but i also need a portable mechanism which
would work for both processes and threads. and i don't want to use
file descriptor locks. are there any alternatives to mutexes?

thanks,

best regards,
--
        aspa

 
 
 

sharing Pthread mutexes among processes

Post by Adam Finema » Wed, 13 Jun 2001 23:20:04





> > > i'm writing an application which uses Pthread mutexes for
> > > synchronizing among a group of processes. i've understood
> > > that mutexes can be created in shared memory and then
> > > set as shared. i'm trying do the following on RedHat v6.2
> > > (glibc-2.1.3-22):

> > > pthread_mutexattr_setpshared(&mutex_attr, PTHREAD_PROCESS_SHARED);

> > > this function does not exist in glibc on my system, however.
> > > how do i set the mutex as "shared" on this system?

> > That function is not implemented linux pthreads, so the pshared
> > attribute is not supported.  Are you absolutedly sure that it's
> > necessary?  What are you trying to do?

> do you know if this feature will be supported by linux pthreads?

This function is optional for Posix.1 and required by Unix 98.  Since
the people at GNU are aiming to comply with both of these standards, I'm
sure that they will want to implement this eventually.  However, it's
not currently listed as an open task as of glibc-2.2.3, which probably
means that no one is currently working on it.

Quote:> i'm trying to implement inter-process locks using pthread mutexes
> as in Stevens Unix network programming vol 1, 2e. i've already
> done this using semaphores but i also need a portable mechanism which
> would work for both processes and threads. and i don't want to use
> file descriptor locks. are there any alternatives to mutexes?

What was unsatisfactory about your semaphore solution?  Note that you
must be very careful about possible deadlocks and freeing resources when
using semaphores, but I don't see why they wouldn't work for both
threads and processes.  I'm assuming that you used the (semget, semopt,
semctl) family of functions.

If portability is your concern, perhaps the requirement that it be a
completely portable solution is unrealistic.  You may wish to qualify
that by requiring that your solution supports a finite list of
platforms.  semget() et. al. should be portable between linux and
Solaris, for example.  However, pay attention to the BUGS section of the
linux man pages for these functions.

HTH
--
Adam

 
 
 

sharing Pthread mutexes among processes

Post by Marko Asplun » Sat, 16 Jun 2001 16:38:54



> What was unsatisfactory about your semaphore solution?

well, basically there wasn't anything wrong with it. i just
wanted to implement another, more lightweight mechanism so,
that i could benchmark the options against each other.

i'm using the following code pattern with the Pthread based
syncronization mechanism:

parent:
        shmid = shmget(IPC_PRIVATE, shmsize, SHM_MODE));
        mtxptr = shmat(shmid, 0, 0);
        pthread_mutexattr_init(&mutex_attr);
        pthread_mutexattr_setpshared(&mutex_attr, PTHREAD_PROCESS_SHARED);
        pthread_mutex_init(mtxptr, &mutex_attr);

children:
        mtxptr = shmat(shmid, 0, 0);
        pthread_mutex_lock(mtxptr);

here process 1 uses fork() + exec() for starting the children.
should the children be able to use the mutexes in shared memory
like this on systems which support pthread_mutexattr_setpshared()?

Quote:> Note that you
> must be very careful about possible deadlocks and freeing resources when
> using semaphores, but I don't see why they wouldn't work for both
> threads and processes.

how would you recommend dealing with possible deadlocks? i've tried
to minimize the time spent and code run in a critical section but
sometimes things can still go wrong and for example a lock holder
might be killed which would lead to a deadlock. should somekind of
lock expiration strategy be implemented?

Quote:> I'm assuming that you used the (semget, semopt,
> semctl) family of functions.

yes, i am.

best regards,
--
        aspa

 
 
 

sharing Pthread mutexes among processes

Post by Adam Finema » Sun, 17 Jun 2001 00:22:57




> > What was unsatisfactory about your semaphore solution?

> well, basically there wasn't anything wrong with it. i just
> wanted to implement another, more lightweight mechanism so,
> that i could benchmark the options against each other.

If you're using fork() + exec(), then your mechanism is not
"lightweight" (i.e. not threaded).  Is there a reason why you cannot
implement a solution that actually uses pthreads?

Quote:> i'm using the following code pattern with the Pthread based
> syncronization mechanism:

> parent:
>         shmid = shmget(IPC_PRIVATE, shmsize, SHM_MODE));
>         mtxptr = shmat(shmid, 0, 0);
>         pthread_mutexattr_init(&mutex_attr);
>         pthread_mutexattr_setpshared(&mutex_attr, PTHREAD_PROCESS_SHARED);
>         pthread_mutex_init(mtxptr, &mutex_attr);

> children:
>         mtxptr = shmat(shmid, 0, 0);
>         pthread_mutex_lock(mtxptr);

> here process 1 uses fork() + exec() for starting the children.
> should the children be able to use the mutexes in shared memory
> like this on systems which support pthread_mutexattr_setpshared()?

Yes, I think this should work on such a system.

Quote:> > Note that you
> > must be very careful about possible deadlocks and freeing resources when
> > using semaphores, but I don't see why they wouldn't work for both
> > threads and processes.

> how would you recommend dealing with possible deadlocks? i've tried
> to minimize the time spent and code run in a critical section but
> sometimes things can still go wrong and for example a lock holder
> might be killed which would lead to a deadlock. should somekind of
> lock expiration strategy be implemented?

The academicians would say that if there is only one resource that can
be held, then there can be no deadlock.  In the real world, however, the
possibility that a lock holder is killed without waking up processes
waiting on the lock is certainly a potential deadock.  It's the
programmer's responsibility to make sure that processes clean up after
themselves when exiting, which in this case would include a call to
pthread_mutex_unlock().

I still think, however, that you should consider implementing a solution
that is actually threaded if you want to compare performance.  If the
only difference in the two solutions is the mechanism for locking
resources, then you won't see much of a difference in performance.

--
Adam

 
 
 

sharing Pthread mutexes among processes

Post by Adam Finema » Sun, 17 Jun 2001 00:38:31



> pthreads-the-standard specifices PTHREAD_PROCESS_SHARED
> (as an option?), but linuxthreads-the-implementation currently does
> not support PTHREAD_PROCESS_SHARED.

"pthread-the-standard" is POSIX 1003.1c, and yes,
_POSIX_THREAD_PROCESS_SHARED is an option.  If
_POSIX_THREAD_PROCESS_SHARED is defined by <unistd.h>, then
pthread_mutexattr_setpshared() must be implemented.  Since
_POSIX_THREAD_PROCESS_SHARED is not defined for Linux, Linux complies
with the standard in this regard.

--
Adam

 
 
 

sharing Pthread mutexes among processes

Post by Marko Asplun » Tue, 24 Jul 2001 18:47:16





> > > What was unsatisfactory about your semaphore solution?

> > well, basically there wasn't anything wrong with it. i just
> > wanted to implement another, more lightweight mechanism so,
> > that i could benchmark the options against each other.

> If you're using fork() + exec(), then your mechanism is not
> "lightweight" (i.e. not threaded).  Is there a reason why you cannot
> implement a solution that actually uses pthreads?
> ...

i'm implementing a request dispatcher library for use with
servers written in Perl (and other) language(s). not all of these
languages have Pthread support (Perl doesn't). this is why
the "process model" that the library uses has to be based
on using processes and not threads.

you mentioned the glibc todo list in an earlier post - could
you give me a pointer to it.

best regards,
--
        aspa

 
 
 

sharing Pthread mutexes among processes

Post by Adam Finema » Tue, 24 Jul 2001 20:44:18


<snip>

Quote:> you mentioned the glibc todo list in an earlier post - could
> you give me a pointer to it.

Check out the PROJECTS file in your glibc distribution.  If you
installed it as a package, it may have been installed under /usr/doc.

- Adam

--
Adam Fineman
Software Engineer
QA Department
TimeSys Corporation
4516 Henry Street
Pittsburgh, PA 15203

Opinions expressed here are my own, and don't necessarily reflect those
of TimeSys Corporation.

 
 
 

1. How do you implement a shared memory mutex among processes?

Hello.

I have several processes which are doing file I/O (c++) and they have
to be serialized at certain points.  

It is very attractive to implement this with a mutex on shared memory
obtained from shmget and friends.  I don't know what the proper
synchronization prims are however.  

Ideally I'd like:

  - lock/unlock primitives that operate on memory - test and set is
    sufficient but whatever is there is ok with me.

  - I'd like it to be compatible with similar stuff on HP/UX if
    possible.

File locking will work for most of this this but an in ram
struct/object with appropriate locking would be much mo' better.

If you have suggestions I'd be grateful.

Dick Norton

2. NetBSD on Zip disk

3. shared memory semaphores / pthread mutexes?

4. Help with Video settings for iMac DV Special Edition

5. How to share data structures among processes?

6. 2 Hard disks question

7. Descriptor sharing among processes

8. How can I use all 128 MB of RAM?

9. Mutex shared between Processes

10. Process-Shared Mutex (futex) - What is it good for ?

11. mutex shared by processes

12. Process Shared Mutexes in AIX 4.3.3rml08?

13. process shared mutexes