From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: erik quanstrom Date: Fri, 10 Aug 2007 12:30:18 -0400 To: 9fans@cse.psu.edu Subject: Re: [9fans] does qlock(2) block all threads on a proc? In-Reply-To: <8ccc8ba40708100916o5bdf7c3eof067224764c06fd0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: a473d136-ead2-11e9-9d60-3106f5b1d025 > 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