From owner-freebsd-hackers  Tue Jan  5 16:09:16 1999
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id QAA08748
          for freebsd-hackers-outgoing; Tue, 5 Jan 1999 16:09:16 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08742
          for <hackers@FreeBSD.ORG>; Tue, 5 Jan 1999 16:09:14 -0800 (PST)
          (envelope-from tlambert@usr05.primenet.com)
Received: (from daemon@localhost)
	by smtp03.primenet.com (8.8.8/8.8.8) id RAA05998;
	Tue, 5 Jan 1999 17:08:36 -0700 (MST)
Received: from usr05.primenet.com(206.165.6.205)
 via SMTP by smtp03.primenet.com, id smtpd005955; Tue Jan  5 17:08:30 1999
Received: (from tlambert@localhost)
	by usr05.primenet.com (8.8.5/8.8.5) id RAA20555;
	Tue, 5 Jan 1999 17:08:29 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199901060008.RAA20555@usr05.primenet.com>
Subject: Re: question about re-entrancy.
To: nate@mt.sri.com (Nate Williams)
Date: Wed, 6 Jan 1999 00:08:28 +0000 (GMT)
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
In-Reply-To: <199901052242.PAA10308@mt.sri.com> from "Nate Williams" at Jan 5, 99 03:42:00 pm
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > >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