Date: Tue, 31 Mar 2009 15:56:07 -0400 From: Randall Stewart <rrs@lakerest.net> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: WITNESS for pthreads Message-ID: <989B6D28-243F-4A13-8C9D-F9C1CD5C2D77@lakerest.net> In-Reply-To: <200903311127.06447.jhb@freebsd.org> References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <200903311038.43401.jhb@freebsd.org> <F0D957B2-E451-4F83-8C30-4A73140470B6@lakerest.net> <200903311127.06447.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 adding.. > > >> <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 > WITNESS > 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 lock ordering across multiple processes ;-) R > > > -- > John Baldwin > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?989B6D28-243F-4A13-8C9D-F9C1CD5C2D77>