[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference clt::cma

Title:	DECthreads Conference

Moderator:	PTHRED::MARYSTEON

Created:	Mon May 14 1990
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1553
Total number of notes:	9541

1494.0. "mutexes / PTHREAD_PROCESS_SHARED attribute ?" by TAEC::URAGO () Tue Feb 25 1997 11:15

Hi All,

I read the following in SUNOS 5.5 documentation about mutex attributes
(same for condition variables) :

     In POSIX, the attributes of a mutex may be specified via the
     attribute  object  created  via pthread_mutexattr_init() and
     modified  using  the  pthread_mutexattr_*()  functions.   To
     explicitly  specify  whether  a  mutex  is  or is not shared
     between processes, it can be initialized with  an  attribute
     object  modified  via pthread_mutexattr_setpshared(3T).  The
     second argument to this function can be either of  the  fol-
     lowing:

     PTHREAD_PROCESS_PRIVATE       The  mutex   can   synchronize
                                   threads  within  this process.
                                   .....

     PTHREAD_PROCESS_SHARED        The  mutex   can   synchronize
                                   threads  in  this  process and
                                  other  processes.   Only   one
                                   process  should initialize the
                                   mutex.
                                   .....


My questions are :

- Is the PTHREAD_PROCESS_SHARED attribute part of the POSIX 1003.1c standard ?

- Do we plan to support it in futur D-UNIX releases ?

Best regards,
Jean-marie.

T.R	Title	User	Personal Name	Date	Lines
1494.1	Yes.	WTFN::SCALES	Despair is appropriate and inevitable.	`Tue Feb 25 1997 11:28`	10
	.0> Is the PTHREAD_PROCESS_SHARED attribute part of the POSIX 1003.1c standard ? Yes: it is one of the optional parts of the standard. .0> Do we plan to support it in futur D-UNIX releases ? Yes. (In "Steel", I believe.) Webb
1494.2	Alternative?	HYDRA::BRYANT		`Wed Mar 12 1997 10:48`	16
	I have a partner who uses functions under Sun. Specifically pthread_mutexattr_setpshared() and pthread_mutexattr_getpshared(). They are porting their application to Digital UNIX and are considering using the IPC semaphores (semget(), semctl(), semop()) as an alternative. They are wondering if when a process tries to acquire a semaphore, the man page says it sleeps if the semaphore has a zero value. Does this mean the entire process goes to sleep or just the thread that made the call? If it's the former this alternative won't do since they need to continue multi-threading while waiting. Can anyone comment on whether or not this alternative is the best approach? Thanks. Pat Bryant Software Partner Engineering
1494.3		DCETHD::BUTENHOF	Dave Butenhof, DECthreads	`Wed Mar 12 1997 11:18`	10
	Digital UNIX never blocks "processes" -- in fact it would be extremely difficult to block a process, since there's no such thing. (Not impossible, of course, but the kernel would have to loop through the task to find all threads, and block each one, which would be silly.) Anything that might seem to block a process will actually block a thread, even if it was never coded to block "only" a thread. (Since the special case coding would be the other way around.) /dave
1494.4	Yes, using semaphores would be fine.	WTFN::SCALES	Despair is appropriate and inevitable.	`Wed Mar 12 1997 12:15`	7
	.2> Can anyone comment on whether or not this alternative is the best approach? Yes, this is probably the best approach. IMO, it is superior to using pshared mutexes, ignoring the fact that Digital Unix doesn't provide them (currently). Webb
1494.5	Why not posix semaphores?	FREE::CAMBRIA	Still worrying about deck chairs	`Thu Mar 13 1997 10:41`	17
	> <<< Note 1494.2 by HYDRA::BRYANT >>> > -< Alternative? >- > >I have a partner who uses functions under Sun. Specifically >pthread_mutexattr_setpshared() and pthread_mutexattr_getpshared(). They are >porting their application to Digital UNIX and are considering using the IPC >semaphores (semget(), semctl(), semop()) as an alternative. PMJI, I'm curious, have they considered using sem_open(), sem_post(), sem_wait(), sem_close() etc. vs. the old SYS V IPC semaphores? If so, why have they choses the "old" way? Thanks, MikeC
1494.6	They didn't know about them	HYDRA::BRYANT		`Fri Mar 14 1997 11:52`	2
	They took at look these news ones and quote "They provide a much saner and usable interface. Thanks."