Date: Fri, 11 Aug 2006 13:29:52 -0400 From: John Baldwin <jhb@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: Divacky Roman <xdivac02@stud.fit.vutbr.cz>, Perforce Change Reviews <perforce@freebsd.org>, Roman Divacky <rdivacky@freebsd.org> Subject: Re: PERFORCE change 103633 for review Message-ID: <200608111329.52886.jhb@freebsd.org> In-Reply-To: <20060811181817.C8215@fledge.watson.org> References: <200608111110.k7BBAxIO059339@repoman.freebsd.org> <200608111249.44686.jhb@freebsd.org> <20060811181817.C8215@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 11 August 2006 13:20, Robert Watson wrote: > On Fri, 11 Aug 2006, John Baldwin wrote: > > >> I think the main problem (which is now fixed) was with this: > >> > >> copyin(addr, val1); > >> if (val1 == val2) > >> .... > >> > >> being non-atomic. On the other hand I tried to use other locks other then > >> Giant and it didnt work. I hope to investigate that later. Now I have this > >> working and my focus is elsewhere. > > > > No, what you have done is wrong. The idea of doing copyin() and then > > compare is just plain not going to work. :) You will need to use > > casuptr() or the like similar to the umtx code. This is assuming that a > > futex can be manipulated from userland w/o entering the kernel. > > I assume that we can basically just do whatever Linux does here for > synchronization... Yes, but my assumption is that it lets the easy cases just run in userland and only goes into the kernel for a hard case, so you need to use atomic ops such as casuptr(). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200608111329.52886.jhb>