Date: Sun, 12 Apr 2009 15:23:51 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Randall Stewart <rrs@lakerest.net> Cc: threads@freebsd.org Subject: Re: A mutex for inter-process ;-) Message-ID: <Pine.GSO.4.64.0904121520040.21490@sea.ntplx.net> In-Reply-To: <AC51CC6F-D157-4BFD-9FA6-8038DEBE1C68@lakerest.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> <AC51CC6F-D157-4BFD-9FA6-8038DEBE1C68@lakerest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 8 Apr 2009, Randall Stewart wrote: > 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. Please see my original reply to this: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=12714+0+archive/2009/freebsd-threads/20090405.freebsd-threads "... and to change our current mutex (and cv) types to be structs instead of pointers." -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0904121520040.21490>