Date: Tue, 5 Jan 1999 17:13:20 -0700 From: Nate Williams <nate@mt.sri.com> To: Terry Lambert <tlambert@primenet.com> Cc: nate@mt.sri.com (Nate Williams), rb@gid.co.uk, narvi@haldjas.folklore.ee, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <199901060013.RAA11201@mt.sri.com> In-Reply-To: <199901060008.RAA20555@usr05.primenet.com> References: <199901052242.PAA10308@mt.sri.com> <199901060008.RAA20555@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > >A 'critical section of code' is a portion of the code that is accessing
> > > >a shared resource, which can be protected by using an object lock.
> > >
> > > Erm, make that "...accessing *one or more* shared resources.", which is why
> > > it isn't the same thing as an object lock (except in the degenerate case).
> >
> > Sure it is. The object lock is used to 'protect' the shared resources.
> > This is multithreading/tasking 101 stuff, not rocket science.
>
>
> OK.
>
> Think about it like this.
>
> I have an object that's on two lists at the same time:
>
> struct some_object {
> struct some_object *list_1_next;
> struct some_object *list_1_prev;
> struct some_object *list_2_next;
> struct some_object *list_2_prev;
> ...
> }
>
> This happens all the time with all sorts of kernel structures.
>
>
> If I have a lock associated with the object, I have two functions:
>
> LRU_object_on_list_1( struct some_object *objp)
> {
> LOCK(objp);
> move_to_head( &objp->list_1_next, list_1_head);
> UNLOCK(objp);
> }
>
> LRU_object_on_list_2( struct some_object *objp)
> {
> LOCK(objp);
> move_to_head( &objp->list_2_next, list_2_head);
> UNLOCK(objp);
> }
>
> Notice that I can't enter both at the same time without blocking
> because I'm locking the object instead of the code.
That's one way of doing it, yes. If the *only* place where both lists
was being modified was a single piece of code, then you don't need to
lock-down both lists separately, hence you could use a single lock.
If you there are multiple places where the list could be locked down,
you have no choice in the matter. You *must* use object locks, (or
something similar to them), else you end up with the 'Big Giant Lock'
problem.
> Yes, this is a gross oversimplification: I could deal with this
> with list locks or two locks associated with the object, or whatever.
> But to obtain the list lock, I'd need to lock the object anyway
> before it was safe to dereference the pointer and acquire the lock
> on the list object (assuming that you had to lock the list object
> to remove references to it).
Right, and how do you propose to do this w/out object locks?
Nate
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?199901060013.RAA11201>