Date: Wed, 8 Apr 2009 14:08:19 -0400 From: Randall Stewart <rrs@lakerest.net> To: Daniel Eischen <deischen@freebsd.org> Cc: threads@freebsd.org Subject: Re: A mutex for inter-process ;-) Message-ID: <AC51CC6F-D157-4BFD-9FA6-8038DEBE1C68@lakerest.net> In-Reply-To: <Pine.GSO.4.64.0903310901410.6930@sea.ntplx.net> References: <7D4F6788-0F12-4863-9635-7FADA9115D16@lakerest.net> <Pine.GSO.4.64.0903301719000.2318@sea.ntplx.net> <AC6F7359-28D5-4F92-93AF-43B6AF86FC01@lakerest.net> <Pine.GSO.4.64.0903301935300.2318@sea.ntplx.net> <9157F968-5CCF-451C-9BA0-E12A957D6B38@lakerest.net> <Pine.GSO.4.64.0903310235580.5671@sea.ntplx.net> <081E4C0E-4DD0-45DA-BDFE-89FC2388E1AE@lakerest.net> <Pine.GSO.4.64.0903310901410.6930@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel: Ok due to working on a sun benchmark (libMicro) I have came back to this again :-) Turns our our friends at sun in their benchmark arrange for threads in separate process, all started by the same parent process, to collaborate by using pthread_mutex and pthread_cond variables. These are allocated in the main process and mmap()'d into shared memory. Of course none of this works at all in FreeBSD. The reason being that both the pthread_mutex_init and pthread_cond_init under the covers allocate memory for the real pthread_mutex or pthread_cond structure.. not the pointer the user hangs on to. So sun's benchmarks all hang if multiple process are involved since they all go to wait on a local condition variable ;-) I suppose in Sun's Solaris the pthread_mutex structure is the entire structure so that when they mmap it they get it all in shm... So, what really needs to be done here is we rework the pthread_cond/mutex to allowed the shared attribute that they are setting (yes they do this) to actually do something. Of course just being aware of the issue does not solve the problem.. since you really need to NOT malloc inside the cond/mutex init code to make this work.. and instead make the "private" structures setup so the user can malloc these. I did notice that the underlying thr_ library allows one to pass in a allocator .. this might be useful except for it does not fit in the posix model. I am not sure how to proceed with this, since it would take some re-work in the thread library... I could do it but I am sure I would not do it the way y'all would like :-) So for now I am going to see about expanding my little toy library that uses umtx to include cond variables and then adapt the sun libMicro to use that so I can move forward with all of their benchmarks that do multi-process stuff :-) R ------------------------------ 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?AC51CC6F-D157-4BFD-9FA6-8038DEBE1C68>