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

["Francisco J Ballesteros" <nemo@lsub.org>]

(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
>