Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Jan 1997 20:37:34 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        Andrew.Gordon@net-tel.co.uk
Cc:        rminnich@Sarnoff.COM, freebsd-hackers@FreeBSD.org
Subject:   Re: Re(2): Using rfork() / threads
Message-ID:  <199701310337.UAA01418@phaeton.artisoft.com>
In-Reply-To: <"40b1-970131030103-8AD9*/G=Andrew/S=Gordon/O=NET-TEL Computer from "Andrew.Gordon@net-tel.co.uk" at Jan 31, 97 03:01:17 am

next in thread | raw e-mail | index | archive | help
> > VM space handling is a little different. If you request VM space sharing,
> > you don't exactly get Vm address space sharing:  what you get is instead
> > shared data areas where in normal fork they are copied. More details on 
> > request. The effect is what you want, though: shared data areas. 
> 
> What synchronization primitives are you supposed to use between two
> rfork()ed processes?  Using SysV sepmaphores seems a bit perverse
> (and would they even work in the environment after a rfork() ?),
> but talking through pairs of sockets to lock small datastructures
> seems a bit heavyweight. 

You use processor test-and-set (CMPTST) on a shared region.

If you want SMP cache coherency for the same situation, you write
a kernel module that uses IPI invalidation queueing.

Time for a set of mutex libraries that are SMP aware?  It would
be easier in elf so you could constructorize the mutex initialization
to decide whether or not to make kernel or non-kernel calls at load
time.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701310337.UAA01418>