Date: Thu, 21 Dec 2000 13:34:15 -0800 From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@FreeBSD.org> Cc: archie@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: looking for locking advice.. Message-ID: <3A427757.8E9D0204@elischer.org> References: <XFMail.001221104751.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > > Julian, > > Just use reader/writer locks for now. They can use a lockmgr backend until a > more efficient reader/writer lock is implemented. As a side note, we should > probably work up a rw lock API and define some macros that just map to lockmgr > operations for now but can be optimized later. Having been looking at r/w locks for a week or two now I see several differnt kinds of rw locks: locks that sleep.. ok but us it efficient? locks that spin.. this is real tricky because interrupts need to be blocked and since there are multiple readers you can't assume that they finish in any particular order so you don't know which interrupt state to restore. I gave up on this idea. locks that just return on failure to atain, and let the higher level code decide what to do. I have also for data going through netgraph r/w locks that on failure, simply queue the packet for use later.. they never block and it really looks sweet for that application. > As for mutexes: you should be > using sleep mutexes, not spin mutexes, in which case interrupts aren't disabled > while the lock is held. Fine, I just wasn't sure what the status of that was.. what is the recommended way to 'sleep'? > Very, very, very, very few things should be using spin > mutexes. I spin for my r/w node locks but I think that on averae they'll be spinning for about 10 cycles as I'm only serialising VERY short operations. > Note that when a mutex is released, if any threads are blocked on it, > then the thread with the highest priority is woken up so it can run. Also note > that interrupt threads have a higher priority than all other threads, so yes, > you can block in an interrupt thread. good.. is there priority inherritence for the fellow that holds the lock I'm waiting for? > However, blocking an interrupt thread > is something that should still be somewhat minimized due to shared interrupts > since you will be blocking all interrupt handlers associated with a particular > interrupt source, thus don't go using tsleep() in an interrupt handler, for > example. :) That's understood.. I presume I can't get another of the same interrupt while processing the last one? All I really want to do is ensure that if I am updating a tree or hash-table, that no-one else is navigating that structure at that time. The updates should be very fast (insert/delete single node), and the navigations should be equally fast. The optimum action would be: spin if it's another processor you are waiting on (and it's running), and yield to it if it's the same processor, and you've pre-empted it. Unfortunatly I don't think that is practical at this time. Maybe a simple version would be the "spin for 100 cycles and then sleep" version.. (if it were an MP machine) Maybe locks should have 'processor held by' as one of their fields.. I guess you could get it indirectly via the proc structure..... > > -- > > John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A427757.8E9D0204>