9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Sape Mullender <sape@plan9.bell-labs.com>
To: 9fans@9fans.net
Subject: Re: [9fans] rwlocks on plan9
Date: Thu, 22 Sep 2011 13:42:32 +0200	[thread overview]
Message-ID: <0be23071bff3cc256237860541549da6@plan9.cs.bell-labs.com> (raw)
In-Reply-To: <d4dae137a381e610157b08c0221df288@quintile.net>

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




  reply	other threads:[~2011-09-22 11:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-22 11:22 Steve Simon
2011-09-22 11:42 ` Sape Mullender [this message]
2011-09-22 11:46 ` Charles Forsyth
2011-09-22 19:33 Steve Simon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0be23071bff3cc256237860541549da6@plan9.cs.bell-labs.com \
    --to=sape@plan9.bell-labs.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).