Date: Tue, 15 Aug 2000 20:41:31 +0200 From: Jonas Bulow <jonas.bulow@servicefactory.se> To: John Polstra <jdp@polstra.com> Cc: hackers@freebsd.org Subject: Re: IPC, shared memory, syncronization AND threads... Message-ID: <39998ED9.561D9751@servicefactory.se> References: <39943C37.76D2DBCC@servicefactory.se> <3995431A.324F8C89@servicefactory.se> <200008121639.JAA63479@vashon.polstra.com> <3997BD3E.2B65AD19@servicefactory.se> <200008151613.JAA04129@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John Polstra wrote: > > In article <3997BD3E.2B65AD19@servicefactory.se>, Jonas Bulow > <jonas.bulow@servicefactory.se> wrote: > > John Polstra wrote: > Actually I thought about this some more, and I'm not all that sure > it's possible. I haven't actually _tried_ it, but I think you'd end > up needing a low-level mutex around parts of the code. That would > have to be implemented as a spinlock, which is exactly what we're > trying to avoid in this exercise. What do you mean with low-level mutex? I mean, how low is low? :-) After doing some more thinking about the cmpxchgl-lock, it's quite hard to use it together with a technique involving the kernel. It will be a contradiction in many ways. I would be nice to have kqueue a EVFILT_MEM and wait for the contents of a memory adress contain a specific value (or other condition like threshold, range entrance/leaving). Then it can be used to wait for the adress used with cmpxchgl. Well, this was just thinking for this very moment. > > > don't know it it's bad design to have rtld.c export > > lockdflt_init in the same way as dlopen, what di you think? > > Right, bad design. :-) just cheking.. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39998ED9.561D9751>