Date: Wed, 6 Jan 1999 01:02:42 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: tlambert@primenet.com, nate@mt.sri.com, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <199901060102.SAA22729@usr05.primenet.com> In-Reply-To: <199901060022.RAA11275@mt.sri.com> from "Nate Williams" at Jan 5, 99 05:22:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Basically, if you lock the code, you can enter the object multiple > > times for non-conflicting code, but if you lock the object, you can > > only enter it once. > > Not necessarily. A good locking implementation can realize that you've > already gotten the lock, and can let you continue to keep it. > (References, etc..) Not too difficult to do, as long as you can > uniquely ID each individual 'thread of execution'. This is true if you are locking from the same thread. My hidden assumption, which I guess I didn't communicate very well, even though I thought it was clear in context of the discussion is that you have two different entities trying to enter the object. A prime example of a place where this happens with great frequency is the /tmp directory, with all sorts of processes creating all sorts of temporary files. For example, a "make -j8" on an 8 CPU machine can beat the hell out of the directory vnode, and will end up not giving you the throughput you expect because of this, even though there's relatively little "real" contention for the create, since most of the time is spent in the read-traversal of the directory entry blocks already there to make sure the file that's to be created doesn't already exist. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199901060102.SAA22729>