WITNESS for pthreads

Randall Stewart rrs at lakerest.net
Tue Mar 31 12:56:12 PDT 2009

On Mar 31, 2009, at 11:27 AM, John Baldwin wrote:

> On Tuesday 31 March 2009 11:11:02 am Randall Stewart wrote:
>> This was one of the places I was heading (as I wrote privately to
>> Daniel ;-D)
>> I suppose I can share it all i.e. the pthread mutex stuff
>> will of course work with shared mutexe's but it won't:
>> a) Build an easy to use semantic for the app to agree on sharing
>> memory.. i.e. you
>>   have left undefined how the process figure out what they are
>> sharing. There is
>>   some value in setting up a easy semantic for app dev's to use.
> You can use shm_open() to share memory regions by name and then  
> create mutexes
> and condvars in that.

Thats what my little ipc_mutex...() functions do ;-)

>> <i.e. insert the mmap and all the other goo through an additional
>> interface>
>> b) What happens when a process exits or hits a core dump while  
>> holding
>> one
>>   of these mutex's? Is this what you are thinking the PROCESS_SHARED
>> would
>>   do??
> There is a "robust" mutex extension David Xu mentioned.  Presumably  
> though
> what would happen is that when one thread went to block on a mutex,  
> the
> kernel (in the umtx code) would see if the current owning thread had  
> exited,
> and if so, do something "appropriate" (break the lock, etc.) at that  
> time.  I
> think a (pid, tid, process starttime) tuple would work ok for  
> detecting this.

If that is implemented.. I need to go look into this.. what I found
when I was doing some digging is that umtx was used.. and I saw
no way to make them "robust".. it may be something that needs

>> <i.e. I don't think a process by itself can fully solve this... maybe
>> the
>>    PROCESS_SHARED could be made to help here>
>> c) If you build something to do <a> so you have some nice way of  
>> naming
>>   mutex's you can do something similar to our WITNESS option in the
>>   kernel... this is something the few times I have played in user
>>   space recently that I have missed... having LOR warnings and such
>>   can be a useful tool. You can't have this without <a> IMO.
>> I was am interested in a/b but one of my long term intents is to do
>> <c> ;-)
> All my WITNESS thoughts are completely separate from PROCESS_SHARED  
> mutexes
> and I think actually break PROCESS_SHARED mutexes.  (Though perhaps  
> they can
> still be made to work but using something far more invasive where  
> defines its own pthread_mutex structure that the app has to be  
> compiled
> against.)

Which could also be put in shared memory so that you could learn the  
ordering across multiple processes ;-)


> -- 
> John Baldwin

Randall Stewart
803-317-4952 (cell)

More information about the freebsd-threads mailing list