[9fans] does qlock(2) block all threads on a proc?

[9fans] does qlock(2) block all threads on a proc?

[david jeannot]

Hi,

Does qlock block all threads on a same proc?
I read lock(2) and thread(2) but I am not sure yet.

Merci beaucoup, david

Re: [9fans] does qlock(2) block all threads on a proc?

[Kris Maglione]

On Fri, Aug 10, 2007 at 02:14:32AM +0200, david jeannot wrote:
>Does qlock block all threads on a same proc?
>I read lock(2) and thread(2) but I am not sure yet.

There are two very good ways for you to answer that question 
(lookman aside). One is to investigate the relevant libthread 
and libc code. The other is to test it yourself. Both are simple  
and quick. I don't know of a better way to learn than 
investigation.

-- 
Kris Maglione

Beware of the physician who is great at getting
out of trouble.

Re: [9fans] does qlock(2) block all threads on a proc?

[erik quanstrom]

qlock(2) doesn't block all threads in a proc.  i'm terrible
at explaining code, but here it goes....

from the source, you'll see that the thread library sets
up (/sys/src/libthread/main.c:35)

	_qlockinit(_threadrendezvous);

what does this do?  in /sys/src/libc/9sys/qlock.c we see
that this just sets a function pointer used in qlock.

qlock returns if unlocked otherwise calls the function
ptr set by _qlockinit() until it returns a magic value.

back in the thread library (/sys/src/libthread/rendez.c)
we find _threadrendezvous.  _threadrendezvous has
two cases.  there is a matching tag (somebody's waiting
to rendezvous with us), and there isn't.  the first case
is qunlock.  the second is qlock when the lock is locked.

in that case, we set set up for going to sleep and then
let _sched give the processor to another thread.

here's some code that shows how this works:

#include<u.h>
#include<libc.h>
#include<thread.h>

QLock q;

void
lockthread(void*)
{
	qlock(&q);
	for(;;){
		print("lockthread\n");
		sleep(100);
		yield();
	}
	qunlock(&q);
}

void
noisethread(void*)
{
	for(;;){
		print("hi mom\n");
		sleep(100);
		yield();
	}
}

void
threadmain(int, char**)
{
	threadcreate(noisethread, 0, 32*1024);
	threadcreate(lockthread, 0, 32*1024);
	yield();

	while(sleep(100) != -1){
		qlock(&q);

		/* never gets here */
		print("thread library confused\n");
		yield();
		qunlock(&q);
	}

	threadexitsall("");
}

perhaps qlock should be added to the man page in the
list of yielding functions.

- erik

Re: [9fans] does qlock(2) block all threads on a proc?

[Francisco J Ballesteros]

It's a queueing lock, but otherwise just a lock. Thus, you use it like
lock(), that is

qlock(&l);
...isolated access to your shared data...
qunlock(&l);

The difference wrt lock/unlock is that it does not spin.  If the lock
cannot be set, the
thread is put to sleep in queue waiting for the lock. So, it's better
to use qlock in
general than it is to use lock. (IIRC, lock is used to protect the
data structure of the QLock,
that might give you more insight regarding the difference b/w qlock and lock).

hth



On 8/10/07, david jeannot <djeannot24@gmail.com> wrote:
> Hi,
>
> Does qlock block all threads on a same proc?
> I read lock(2) and thread(2) but I am not sure yet.
>
> Merci beaucoup, david
>

Re: [9fans] does qlock(2) block all threads on a proc?

[erik quanstrom]

> The difference wrt lock/unlock is that it does not spin.  If the lock
> cannot be set, the
> thread is put to sleep in queue waiting for the lock. So, it's better
> to use qlock in
> general than it is to use lock. (IIRC, lock is used to protect the
> data structure of the QLock,
> that might give you more insight regarding the difference b/w qlock and lock).

pardon my pedantic streak.  but i don't think that classifying one
type of lock as "better" helps straighten things out.  one selects 
the right lock for the job.

in some cases, going to sleep is not an option.  in some cases
frequency of access makes qlocks impractical.  if you don't have 
a process (like in an interrupt context), you can't qlock.

*all locks spin*.  the difference between a qlock and a normal lock
is that an outer lock protects the inner lock.  a qlock will spin
aquiring the outer lock.  if the inner lock is locked, qlock places
the calling proc on the queue of waiters, releases the lock and
"waits" for its turn.  what wait means depends on the context.
the easiest code to follow is in /sys/src/9/port/qlock.c.  userland
qlocks slightly differently.

- erik

Re: [9fans] does qlock(2) block all threads on a proc?

[Francisco J Ballesteros]

(all the time thinking about using them from userland)

the point is that the tas lock is just used to secure the QLock struct, and it's
not likely that the Lock in the QLock would be set for too long. Thus, IMHO
it's better just to use qlocks so your thread gets out of the way until it could
get the lock. Again, I'm referring to user programs using the thread library.

In the kernel, it depends. But because of the mention of thread(2) in
the original
post,  I think the
question was about user programs using libthread.

On 8/10/07, erik quanstrom <quanstro@quanstro.net> wrote:
> > The difference wrt lock/unlock is that it does not spin.  If the lock
> > cannot be set, the
> > thread is put to sleep in queue waiting for the lock. So, it's better
> > to use qlock in
> > general than it is to use lock. (IIRC, lock is used to protect the
> > data structure of the QLock,
> > that might give you more insight regarding the difference b/w qlock and lock).
>
> pardon my pedantic streak.  but i don't think that classifying one
> type of lock as "better" helps straighten things out.  one selects
> the right lock for the job.
>
> in some cases, going to sleep is not an option.  in some cases
> frequency of access makes qlocks impractical.  if you don't have
> a process (like in an interrupt context), you can't qlock.
>
> *all locks spin*.  the difference between a qlock and a normal lock
> is that an outer lock protects the inner lock.  a qlock will spin
> aquiring the outer lock.  if the inner lock is locked, qlock places
> the calling proc on the queue of waiters, releases the lock and
> "waits" for its turn.  what wait means depends on the context.
> the easiest code to follow is in /sys/src/9/port/qlock.c.  userland
> qlocks slightly differently.
>
> - erik
>