From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
Date: Thu, 22 Sep 2011 13:42:32 +0200
From: Sape Mullender <sape@plan9.bell-labs.com>
Message-ID: <0be23071bff3cc256237860541549da6@plan9.cs.bell-labs.com>
In-Reply-To: <d4dae137a381e610157b08c0221df288@quintile.net>
References: <d4dae137a381e610157b08c0221df288@quintile.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [9fans] rwlocks on plan9
Topicbox-Message-UUID: 2ba1c902-ead7-11e9-9d60-3106f5b1d025

It's how read and write locks are supposed to work, but your
example isn't necessarily how they should be used.

The idea is that a piece of data can be kept consistent by *either*
• allowing any number of simultaneous readers *or*
• a single writer.
You can't have simultaneous readers and writers because the
readers might not read the data consistently if they're allowed
to read while writing is in progress.

The locks reflect the notion that we'd like to achieve maximum
concurrency.

Now, it wouldn't hurt, one would think, if one process takes a
read lock and then adds a write lock.  The locking system could
recognize it's one and the same process and allow it.  When
adding the write lock (or converting to the write lock), the
process doing it would have to wait until all other readers have
released their locks.

The alternative is also possible: after makinga  change to the object,
a process could convert its write lock to a read lock and "know" that
it's now reading the data produced moments ago.

The problem is that this (and many other activities involving
more than one lock) can lead to deadlock.

In your example, the recommended approach is that, if you're thinking
of modifying an object, you use a write lock, even if the change
doesn't have to occur because some pattern wasn't found.

It's okay to read a file with a write lock.  Think of it as
an exclusive lock rather than a write lock.

	Sape

> Its quite possible that I'am doing somthing foolish,
> but just in case its in the design...
>
> It appears to me that when using rwlocks on plan9
> I have to release the read lock before I can take the write lock
> in a process - i.e. a single process cannot hold both.
>
> This means that when updating a data structure I do this:
>
> 	rlock()
> 	search_structure()
> 	if(found){
> 		runlock()
> 		return
> 	}
> 	runlock()
>
> 	wlock()
> 	search_structure()	# search a seccond time
> 	if(found){			# lost the race
> 		wunlock()
> 		return
> 	}
> 	add_entry()			# won the race
> 	wlock()
> 	return
>
> If I could hold both locks I wouldn't need to do the seccond
> search.
>
> is this how its susposed to work?
>
> -Steve