Date: Wed, 6 Jan 1999 00:08:28 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: rb@gid.co.uk, nate@mt.sri.com, narvi@haldjas.folklore.ee, tlambert@primenet.com, wes@softweyr.com, bright@hotjobs.com, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <199901060008.RAA20555@usr05.primenet.com> In-Reply-To: <199901052242.PAA10308@mt.sri.com> from "Nate Williams" at Jan 5, 99 03:42:00 pm
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.
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).
I can't do the same thing for a user lock list and a VM page list
hung of a a vm_object_t hung off a vnode, as a rather more complicated
and at the same time more real example.
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?199901060008.RAA20555>