pthreads & shared memory
in [Unix Programming]
|
Prev: For thine is the capitalization, the spacing, and the brace question.For ever and ever. On Usenet.
Next: What is the __dead usage macro at the start of a C program for bsd?
From: Geoff Clare on 1 Mar 2010 08:52 David Schwartz wrote: > I don't think you can create a process shared spinlock. pthread_spin_init(&spinlock, PTHREAD_PROCESS_SHARED) -- Geoff Clare <netnews(a)gclare.org.uk>
From: Chris Friesen on 1 Mar 2010 09:44 On 02/26/2010 09:53 PM, David Schwartz wrote: > On Feb 26, 6:01 pm, "~Glynne" <glynnec2...(a)yahoo.com> wrote: > >> Since you're talking about separate *processes* (not threads), you >> could use something much simpler: >> >> // create lock file >> int h= fileno( tmpfile() ); >> lseek( h, 0, SEEK_SET ); >> >> // usage >> lockf( h, F_LOCK, 0 ); >> // >> // do shared memory updates here >> // >> lockf( h, F_ULOCK, 0 ); > > What keeps the memory accesses from migrating around the 'lockf' > calls? Suppose his CPU has a write posting buffer and that posting > buffer holds a write just before the unlock operation and doesn't > commit it to memory/cache until after the unlock completes? I think you're correct that memory barrier behaviour is not guaranteed by the standard. However, given that using fcntl() as an inter-process lock has been around for some time (since before inter-process mutexes were commonly available) it's reasonably likely to work in practice. Various books do mention using file locking (usually fcntl()) as an interprocess lock. Chris
From: Scott Lurndal on 1 Mar 2010 13:20 Chris Friesen <cbf123(a)mail.usask.ca> writes: >On 02/26/2010 09:53 PM, David Schwartz wrote: >> On Feb 26, 6:01 pm, "~Glynne" <glynnec2...(a)yahoo.com> wrote: >> >>> Since you're talking about separate *processes* (not threads), you >>> could use something much simpler: >>> >>> // create lock file >>> int h= fileno( tmpfile() ); >>> lseek( h, 0, SEEK_SET ); >>> >>> // usage >>> lockf( h, F_LOCK, 0 ); >>> // >>> // do shared memory updates here >>> // >>> lockf( h, F_ULOCK, 0 ); >> >> What keeps the memory accesses from migrating around the 'lockf' >> calls? Suppose his CPU has a write posting buffer and that posting >> buffer holds a write just before the unlock operation and doesn't >> commit it to memory/cache until after the unlock completes? > >I think you're correct that memory barrier behaviour is not guaranteed >by the standard. However, given that using fcntl() as an inter-process >lock has been around for some time (since before inter-process mutexes >were commonly available) it's reasonably likely to work in practice. The lockf() call is a sequence point in C, so the compiler cannot reorder accesses around the lockf() call. As for the processor not posting the write, yes, one must take that into account. However, unless the lockf() call is a no-op, it will likely have caused any pending writes from prior to the lockf() call to be posted by the time the lockf() call returns. That said, it's not clear why the OP chose to use fork instead of pthreads. scott
From: David Schwartz on 1 Mar 2010 15:21 On Mar 1, 10:20 am, sc...(a)slp53.sl.home (Scott Lurndal) wrote: > The lockf() call is a sequence point in C, so the compiler cannot reorder > accesses around the lockf() call. Sure it can, under the as-if rule. So long as a compliant program can't tell the difference the compiler can reorder accesses around sequence points. > As for the processor not posting the write, yes, one must take that > into account. However, unless the lockf() call is a no-op, it will likely > have caused any pending writes from prior to the lockf() call to be posted > by the time the lockf() call returns. Right, but code that is "likely" to work tends to actually fail. Much better, it is, to write code that is guaranteed to work. In fact, this is one of the worst "likely to work" cases because it's CPU dependent. Having your application software break when you upgrade your CPU is, to most people I think, very unacceptable. > That said, it's not clear why the OP chose to use fork instead of > pthreads. The OP didn't say why, but there are definitely cases where processes with shared memory makes more sense than threads. DS
From: Chris Friesen on 1 Mar 2010 15:42
On 03/01/2010 12:20 PM, Scott Lurndal wrote: > That said, it's not clear why the OP chose to use fork instead of > pthreads. I can think of a few possibilities: 1) Need to use non-threadsafe libraries. 2) Easier to fork/exec child processes. 3) Improved robustness since the other processes can't trample your whole memory space. 4) Ability to kill/respawn individual processes from the shell. 5) Desire for separate signal handlers in the various processes. Chris |