[9fans] rwlocks on plan9

[9fans] rwlocks on plan9

[Steve Simon]

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

Re: [9fans] rwlocks on plan9

[Sape Mullender]

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

Re: [9fans] rwlocks on plan9

[Charles Forsyth]

>is this how its susposed to work?

yes. the queued locks are associated with data, not with a process:
one process can acquire the lock and another release it.
that probably isn't used often at all, but it's the best way to think of it.
spin locks have a tighter link with a process because (after all)
they're intended for short sections of code without rescheduling.

Re: [9fans] rwlocks on plan9

[Steve Simon]

Thanks to all who replied, I understand rwlocks
a little better now.

-Steve