A mutex for inter-process ;-)

Randall Stewart rrs at lakerest.net
Mon Mar 30 21:47:11 PDT 2009


The actual take I took is that both the
pid and first tid are recorded.

When you start up you validate each pid listed and make
sure the main tid matches and the process is alive.

Now of course there is a chance that both the
tid and pid will wrap.. but both would have to
wrap and you would have to have the new pid be assigned
the same tid during the wrap.

Maybe this would be common.. don't know .. but its a start. Without
adding some sort of hook at process death to detect and cleanup
the shared memory..

R
On Mar 31, 2009, at 12:32 AM, Alfred Perlstein wrote:

> One trick to handling pid wrap is to also record process
> start time.  I sort of wish our signalling code allowed
> this as a optional thing to make _really sure_ you weren't
> signalling the wrong process.
>
> -Alfred
>
> * Randall Stewart <rrs at lakerest.net> [090330 16:29] wrote:
>>
>> On Mar 30, 2009, at 5:16 PM, Xin LI wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Randall Stewart wrote:
>>>> Hi all:
>>>>
>>>> I have recently written a small set of routines that allow
>>>> two process to have a "mutex" between them.. actually it allows
>>>> all of the threads in any set of processes to have mutexes between
>>>> themselves ;-)
>>>>
>>>> Anyway it seems to be working fairly well.. I still have to write a
>>>> man
>>>> page
>>>> for it (documentation always last).. and eventually I would like to
>>>> port in
>>>> some of the WITNESS type features since the mutex's have names..
>>>>
>>>> I probably should also think about scaling it up a bit.. right now
>>>> its
>>>> really
>>>> more for a small scale (100 or less mutexes)...
>>>>
>>>> Who should I talk to about getting this in... having it reviewed
>>>> etc. I
>>>> think
>>>> it belongs in libthr since it really needs the tid of the pthreads
>>>> from the
>>>> pthread_t type... and for now I have a horrible hack in to get  
>>>> it ;-)
>>>
>>> I think davidxu@ deischen@ and julian@?
>>>
>>> BTW.  How do you handle with one process exit (abnormally) without
>>> releasing the mutex?  Just curious :)
>>
>> I have a couple of ways of dealing with this..
>>
>> 1) Of course the initialization routine calls atexit() to get a
>> "cleanup handler" in place.
>> 2) Often times, of course, this can fail e.g. you get a SIGSEGV.. or
>> some such. When you
>>   attach the memory, an audit is done. The audit will validate that
>> the pid is still alive
>>   and has the particular tid in it. Of course this is not 100% but
>> as long as the tid's have
>>   not rolled over it should work. The function is also public (need
>> to add that and many things
>>   to the manual pages ;-D) so that one can call it whenever one
>> wants :-)
>>
>> I will ping Julian and the others...
>>
>> R
>>
>>>
>>>
>>> Cheers,
>>> - --
>>> Xin LI <delphij at delphij.net>	http://www.delphij.net/
>>> FreeBSD - The Power to Serve!
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v2.0.11 (FreeBSD)
>>>
>>> iEYEARECAAYFAknRNrEACgkQi+vbBBjt66DIswCbBWRMJN55c60UTBBIZMRCY4zo
>>> 6hcAnixfVXdtdnn0fT/Z31v0EdyVCVlH
>>> =JL/U
>>> -----END PGP SIGNATURE-----
>>>
>>
>> ------------------------------
>> Randall Stewart
>> 803-317-4952 (cell)
>> 803-345-0391(direct)
>>
>> _______________________________________________
>> freebsd-threads at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
>> To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org 
>> "
>
> -- 
> - Alfred Perlstein
>

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)



More information about the freebsd-threads mailing list