[9fans] qunlock

[9fans] qunlock

[dvd]

calling qunlock on an unlocked QLock is no-op, isn't it?

Re: [9fans] qunlock

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 109 bytes --]

i'd have thought it best to regard it as best avoided.
does it happen, or was it something you wanted to do?

[-- Attachment #2: Type: message/rfc822, Size: 2595 bytes --]

From: dvd@davidashen.net
To: 9fans@cse.psu.edu
Subject: [9fans] qunlock
Date: Tue, 22 Jun 2004 11:04:20 +0500
Message-ID: <259e5ab496f281b48d4e6ad53a58891d@davidashen.net>

calling qunlock on an unlocked QLock is no-op, isn't it?

Re: [9fans] qunlock

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 179 bytes --]

actually, i'd have said such an effect was unusable (or relying on it
was pointless) in general, at least with more than one process, so i'm
now more curious how you'd use it.

[-- Attachment #2: Type: message/rfc822, Size: 5134 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 109 bytes --]

i'd have thought it best to regard it as best avoided.
does it happen, or was it something you wanted to do?

[-- Attachment #2.1.2: Type: message/rfc822, Size: 2595 bytes --]

From: dvd@davidashen.net
To: 9fans@cse.psu.edu
Subject: [9fans] qunlock
Date: Tue, 22 Jun 2004 11:04:20 +0500
Message-ID: <259e5ab496f281b48d4e6ad53a58891d@davidashen.net>

calling qunlock on an unlocked QLock is no-op, isn't it?

Re: [9fans] qunlock

[ron minnich]

On Tue, 22 Jun 2004, C H Forsyth wrote:

> actually, i'd have said such an effect was unusable (or relying on it
> was pointless) in general, at least with more than one process, so i'm
> now more curious how you'd use it.


to me qunlock of an unlock'ed thing should be a cause for panic.

ron

Re: [9fans] qunlock

[boyd, rounin]

> to me qunlock of an unlock'ed thing should be a cause for panic.

seconded.

Re: [9fans] qunlock

[Rob Pike]

if it's already unlocked, don't unlock it.

-rob

Re: [9fans] qunlock

[dvd]

> > calling qunlock on an unlocked QLock is no-op, isn't it?
> 
> i'd have thought it best to regard it as best avoided.
> does it happen, or was it something you wanted to do?
> 

I need to release a qlock in  a criticial session guarded by another lock,

QLock p,q;

void x() {
	qlock(&p);

	if(...)
		qunlock(&q);

	qunlock(&p);
}

void y() {
	qlock(&q);
	qlock(&p);

	qunlock(&p);
}

The question is whether the above is legal or should I write

if(...){
	canqlock(&q);
	qunlock(&q);
}

instead?

Re: [9fans] qunlock

[Rob Pike]

you can't do that. what if you do the first unlock,
then someone else locks it in the interim. you'll
unlock his lock. bad bad bad.

-rob

Re: [9fans] qunlock

[dvd]

> you can't do that. what if you do the first unlock,
> then someone else locks it in the interim. you'll
> unlock his lock. bad bad bad.
> 
> -rob

It happens in a critical section guarded by another mutex. 
Noone else can unlock my lock.

Should I uncomment the commented-out calls below?


void
A()
{
againA:
	qlock(a);
	qlock(q);
		if(x) {
   			qunlock(q);
			goto againA;
		}
	/* canqlock(b); */
	qunlock(b);
	qunlock(q);
	qunlock(a);
}

void
B()
{
againB:
	qlock(b);
	qlock(q);
		if(y){
			qunlock(q);
			goto againB;
		}
	/* canqlock(a); */
	qunlock(a);
	qunlock(q);
	qunlock(b);
}

Re: [9fans] qunlock

[boyd, rounin]

restructure the code and make sure you lock/unlock in the same 'order':

    lock:    A B C D E
    unlock: E D C B A

you could use canlock, but i think yer inviting races.

and get _rid_ of those gotos!

Re: [9fans] qunlock

[Fco. J. Ballesteros]

Maybe it's just that it's too early and I got soo few coffee, but,
do meant this, didn't you?

> void
> A()
> {

	qlock(a);
againA:

> 	qlock(q);
> 		if(x) {
>    			qunlock(q);
> 			goto againA;
> 		}
....


> void
> B()
> {

 	qlock(b);
againB:

> 	qlock(q);
> 		if(y){
> 			qunlock(q);
> 			goto againB;
> 		}
....

Re: [9fans] qunlock

[dvd]

> Maybe it's just that it's too early and I got soo few coffee, but,
> do meant this, didn't you?

No, I didn't; I mean that under certain condition each of the processes
steps aside and opens the way for the other one until the other one executes
at least once. 

The original code does exactly that.  Your changes just spin each of the processes once the corresponding condition becomes true.

> 
>> void
>> A()
>> {
> 
> 	qlock(a);
> againA:
> 
>> 	qlock(q);
>> 		if(x) {
>>    			qunlock(q);
>> 			goto againA;
>> 		}
> ....
> 
> 
>> void
>> B()
>> {
> 
>  	qlock(b);
> againB:
> 
>> 	qlock(q);
>> 		if(y){
>> 			qunlock(q);
>> 			goto againB;
>> 		}
> ....

Re: [9fans] qunlock

[Fco. J. Ballesteros]

> 	/* canqlock(b); */
> 	qunlock(b);

This is very weird for me.
Can't you rework your scheme to avoid such things?
Perhaps this code is suggesting that your locking
conventions may need more work.

Re: [9fans] qunlock

[dvd]

>> 	/* canqlock(b); */
>> 	qunlock(b);
> 
> This is very weird for me.
> Can't you rework your scheme to avoid such things?
> Perhaps this code is suggesting that your locking
> conventions may need more work.

That's why I am asking. What exactly is weird? The code actually works
in SPIN (as a model), and in Python (but I check locked() before unlocking).

The purpose is to have multiple producers and consumers on an queue
with exclusive access, with priority always given to consumers if there
are waiting ones and the queue is not empty.

The implementation of qlock/qunlock allows to unlock when not locked;
I am asking whether it is by design or by a coincidence?

David

Re: [9fans] qunlock

[Fco. J. Ballesteros]

> The purpose is to have multiple producers and consumers on an queue
> with exclusive access, with priority always given to consumers if there
> are waiting ones and the queue is not empty.


Why don't you use channels to implement your sleep/wakeup
mechanism. Using a lock to do so is weird for me, but perhaps others
are used to it.

Re: [9fans] qunlock

[dvd]

>> The purpose is to have multiple producers and consumers on an queue
>> with exclusive access, with priority always given to consumers if there
>> are waiting ones and the queue is not empty.
> 
> 
> Why don't you use channels to implement your sleep/wakeup
> mechanism. Using a lock to do so is weird for me, but perhaps others
> are used to it.

Channels and qlocks are the same thing, aren't they?

Re: [9fans] qunlock

[Fco. J. Ballesteros]

> Channels and qlocks are the same thing, aren't they?

In the end, all might be the same. But a qlock, for me, is
a lock. I acquire it, I release it later. A channel on the other
hand is something that lets me send/recv. That can be used
to do a sleep/wakeup approach, as well as a I want this, take that
one.

Re: [9fans] qunlock

[Sape Mullender]

> The purpose is to have multiple producers and consumers on an queue
> with exclusive access, with priority always given to consumers if there
> are waiting ones and the queue is not empty.

I can imagine one would want to give priority to consumers over producers,
but the danger is that the performance gained by such a thing is more than
offset by the cost of the mechanism.

Putting something on a queue or taking something off is not an expensive
operation.  The number of instructions needed is typically somewhere between
a dozen and a gross.

The queue must be protected by a lock (unless one uses a non-blocking queue
implementation, but that's another story).  QLocks themselves also have queues
and they, in turn, are protected by spin locks.

If your queue is fairly light weight, I would recommend just using lock() and
unlock() to protect them.  When you try to lock when it's already locked, you'll
waste cycles by spinning (but fewer than you might think), but when you use
qlocks — and especially when you use three of them — you'll end up wasting far
more cycles.

I'd say forget about giving priority to consumers; it's not worth it.

	Sape

Re: [9fans] qunlock

[boyd, rounin]

> Channels and qlocks are the same thing, aren't they?

no

Re: [9fans] qunlock

[boyd, rounin]

> The implementation of qlock/qunlock allows to unlock when not locked;
> I am asking whether it is by design or by a coincidence?

i'd say design.  unlocking things that are not locked is a BUG.