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

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

9357.0. "Question about pthreads and System V IPC semaphores" by RDGENG::CHAMBERLIN (Danger! Do not Reverse Polarity) Wed Apr 02 1997 06:01

A partner has asked about using System V IPC semaphores with multiple
multithreaded processes. 

They are looking for a method of synchronising between threads of different
processes. As I understand it, the standard pthread mutexes are internal to the
creating process?

The partner found that on their HP system, the System V IPC semaphore operation
semop() blocked the whole process (all of its threads) at the kernel level,
rather than just the thread which performed the semaphore operation, and leaving
the other threads running.

Does our semop() do the same? Since this is sys V functionality, I would expect
it does, unless our thread implementation makes it different. If so, do we have
a mechanism which will provide the required functionality, eg the P1003.1b
semaphores, sem_xxxx functions?

THanks,
	Ian Chamberlin,

Software Partner Engineering.
T.RTitleUserPersonal
Name
DateLines
9357.1User-mode threads vs. "true threads"DCETHD::BUTENHOFDave Butenhof, DECthreadsWed Apr 02 1997 06:3024
Until the forthcoming HP-UX 10.30, HP does not have "real" threads -- only
the OSF "DCE threads", which operate entirely in user-mode, with no support
(or knowledge) in the kernel. The user-mode thread library (which, by the
way, Digital originally wrote) uses select() and non-blocking I/O mode to
make "most" I/O operations appear to block only the calling thread. However,
that's only partly effective. UNIX typically "lies" about file system I/O,
for example, assuming that the file system cache makes all operations
"instantaneous" -- select() will never admit that the I/O will block. And, of
course, the method won't work for anything that's not supported by select(),
such as semaphores and message queues. Therefore, all such operations
unavoidably block the process.

Digital UNIX has true thread support. In fact, it's nearly impossible to
"block the process" in Digital UNIX, because there's really no such thing as
a process. (It's a set of data structures fabricated in the Mach kernel to
let the rest of the kernel pretend it's UNIX.) Digital UNIX does not schedule
"processes" -- it schedules threads. So, to block a process, some O/S code
would need to find the current Mach task, traverse a queue of threads
associated with that task, and block each of them individually. Of course it
can be done -- but it can't happen by accident or oversight! No standard
kernel blocking call (i.e., I/O operation) does this, so even those that
"don't know about threads" will still only block the calling thread.

	/dave
9357.2thanks dave, glad to see we've got it right over HP!RDGENG::CHAMBERLINDanger! Do not Reverse PolarityWed Apr 02 1997 11:190