From owner-freebsd-hackers@FreeBSD.ORG  Thu Oct  9 12:46:44 2003
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 558)
	id 50B9116A4BF; Thu,  9 Oct 2003 12:46:44 -0700 (PDT)
To: nick@garage.freebsd.pl
Message-Id: <20031009194644.50B9116A4BF@hub.freebsd.org>
Date: Thu,  9 Oct 2003 12:46:44 -0700 (PDT)
From: hsu@FreeBSD.ORG (Jeffrey Hsu)
cc: freebsd-hackers@freebsd.org
Subject: Re: Dynamic reads without locking.
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Oct 2003 19:46:44 -0000

  > I'm wondering...
  > Jeffrey Hsu was talking about this at BSDCon03.
  > There is no need to lock data when we just made simple read, for example:
  > 
  >     mtx_lock(&foo_mtx);
  >     foo = 5;
  >     mtx_unlock(&foo_mtx);
  > but only:
  >     bar = foo;
  > 
  > IMHO this is quite dangerous.
  > Let's see:
  > 
  >     thread1                 thread2
  >     mtx_lock(&foo_mtx);
  >     foo = data_from_user;
  >                             bar = foo;
  >     foo &= MASK;
  >     mtx_unlock(&foo_mtx);
  > 
  > In this case we have really dangerous race if data from user are
  > safe only when we made 'and' operation on them.
  > OR of course we can just store wrong value in 'bar' and this could
  > be case of different problems.

This case (along with some other cases where locks of atomic reads
are required) is covered in the paper as

  But, one case where locks would be required is if the field
  temporarily holds a value that no one else is supposed to see and
  the writer, operating with the lock held, will store a valid value
  before releasing his lock. In this case, both the writer and
  reader need to hold the lock before accessing this field.

						Jeffrey