From owner-freebsd-threads@FreeBSD.ORG Mon Jan 24 11:07:11 2011 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89BC61065779 for ; Mon, 24 Jan 2011 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5D69E8FC21 for ; Mon, 24 Jan 2011 11:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0OB7BX3077954 for ; Mon, 24 Jan 2011 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0OB7At2077950 for freebsd-threads@FreeBSD.org; Mon, 24 Jan 2011 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Jan 2011 11:07:10 GMT Message-Id: <201101241107.p0OB7At2077950@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 11:07:11 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/149366 threads pthread_cleanup_pop never runs the configured routine o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. f threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/76690 threads fork hang in child for -lc_r s threa/69020 threads pthreads library leaks _gc_mutex s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/34536 threads accept() blocks other threads s threa/30464 threads pthread mutex attributes -- pshared 29 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Jan 24 21:04:56 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF13F1065709; Mon, 24 Jan 2011 21:04:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A3DE18FC2D; Mon, 24 Jan 2011 21:04:56 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4741A46B09; Mon, 24 Jan 2011 16:04:56 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4980F8A009; Mon, 24 Jan 2011 16:04:55 -0500 (EST) From: John Baldwin To: David Xu Date: Mon, 24 Jan 2011 16:04:21 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201101241604.21451.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Jan 2011 16:04:55 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: threads@freebsd.org Subject: Try upgrades and downgrades for POSIX rwlocks X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 21:04:56 -0000 Does anyone know if there is a de facto or proposed standard for supporting upgrades and downgrades in POSIX rwlocks? IBM seems to support something rather gross where a wrlock() will succeed if the only shared lock is held by the current thread. But then the thread holds both a read and write lock, and it has to call unlock twice, the first to drop the write lock, the second to drop the read lock. If we were to add support for upgrades and downgrades I would prefer something more along the lines of our in-kernel APIs where there are try_upgrade() and downgrade() operations that convert a given lock between states. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Tue Jan 25 01:33:47 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F2D4106566B; Tue, 25 Jan 2011 01:33:47 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id DF9108FC17; Tue, 25 Jan 2011 01:33:46 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 0927E1A3C41; Mon, 24 Jan 2011 17:18:39 -0800 (PST) Date: Mon, 24 Jan 2011 17:18:39 -0800 From: Alfred Perlstein To: John Baldwin Message-ID: <20110125011839.GK21872@elvis.mu.org> References: <201101241604.21451.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201101241604.21451.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: threads@freebsd.org, David Xu Subject: Re: Try upgrades and downgrades for POSIX rwlocks X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 01:33:47 -0000 * John Baldwin [110124 13:05] wrote: > Does anyone know if there is a de facto or proposed standard for supporting > upgrades and downgrades in POSIX rwlocks? IBM seems to support something > rather gross where a wrlock() will succeed if the only shared lock is held by > the current thread. But then the thread holds both a read and write lock, and > it has to call unlock twice, the first to drop the write lock, the second to > drop the read lock. If we were to add support for upgrades and downgrades I > would prefer something more along the lines of our in-kernel APIs where there > are try_upgrade() and downgrade() operations that convert a given lock between > states. There may a be a tricky problem here. In order to avoid writer starvation (in the kernel) we give writers preference over readers so that many concurrent readers can't keep the lock in a shared-only state forever. (Or at least that's how I left it when I touched it last. :D ) There is a problem here. To conserve that behavior we need to look at the situation of an upgrade: 1) we have to put the upgrader to the front of the writer queue, this can starve other threads looking for only a writer lock by giving an unfair advantage to those that take a share lock first. 2) we don't even look at this issue and we wind up with some deadlock. At a glance, I think we have to have some kind of "try_upgrade" that doesn't give preference to the thread already holding the lock. We should probably strongly encourage try_upgrades to have some sort of fault injection so that a potentially infrequently "missed upgrade" path can be exercised easily. Perhaps with a kernel config option or that fault injection stuff? just some ideas. Maybe there's someone that can explain how IBM does the rwlocks. Why do we want to have our own method. And if our methods are different, does it break the semantics that may become standard across the board? Does it help us to diverge? What about OS X and Solaris? -Alfred From owner-freebsd-threads@FreeBSD.ORG Tue Jan 25 14:21:00 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 585FA106566C; Tue, 25 Jan 2011 14:21:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0888FC24; Tue, 25 Jan 2011 14:21:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8EBDA46B81; Tue, 25 Jan 2011 09:20:59 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5B6718A009; Tue, 25 Jan 2011 09:20:58 -0500 (EST) From: John Baldwin To: Alfred Perlstein Date: Tue, 25 Jan 2011 09:15:38 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.4-CBSD-20110107; KDE/4.4.5; amd64; ; ) References: <201101241604.21451.jhb@freebsd.org> <20110125011839.GK21872@elvis.mu.org> In-Reply-To: <20110125011839.GK21872@elvis.mu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201101250915.38937.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 25 Jan 2011 09:20:58 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: threads@freebsd.org, David Xu Subject: Re: Try upgrades and downgrades for POSIX rwlocks X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 14:21:00 -0000 On Monday, January 24, 2011 8:18:39 pm Alfred Perlstein wrote: > * John Baldwin [110124 13:05] wrote: > > Does anyone know if there is a de facto or proposed standard for supporting > > upgrades and downgrades in POSIX rwlocks? IBM seems to support something > > rather gross where a wrlock() will succeed if the only shared lock is held by > > the current thread. But then the thread holds both a read and write lock, and > > it has to call unlock twice, the first to drop the write lock, the second to > > drop the read lock. If we were to add support for upgrades and downgrades I > > would prefer something more along the lines of our in-kernel APIs where there > > are try_upgrade() and downgrade() operations that convert a given lock between > > states. > > There may a be a tricky problem here. > > In order to avoid writer starvation (in the kernel) we give writers > preference over readers so that many concurrent readers can't keep > the lock in a shared-only state forever. (Or at least that's how I > left it when I touched it last. :D ) > > There is a problem here. > > To conserve that behavior we need to look at the situation of an upgrade: > 1) we have to put the upgrader to the front of the writer queue, > this can starve other threads looking for only a writer lock by > giving an unfair advantage to those that take a share lock first. > > 2) we don't even look at this issue and we wind up with some deadlock. > > At a glance, I think we have to have some kind of "try_upgrade" > that doesn't give preference to the thread already holding the lock. Err, I generally think try_upgrades (which by nature give preference to the current thread since they only succeed if the only shared lock held is that of the current thread) are the only "sane" upgrade operation. If you have any sort of blocking upgrade then you have to handle the problem of two concurrent upgrades in which case at least one upgrade would only be able to succeed after another thread has obtained a write lock and modified the state, and I suspect most programmers don't realize that after a blocking lock upgrade they cannot trust any of the state that they checked under the read lock and instead need to recheck all of that. Having a try_upgrade forces them to handle this since it can fail and in the failure case it is more obvious that you have to reexamine state if you fall back to doing a read lock followed by a blocking write lock. > We should probably strongly encourage try_upgrades to have some sort > of fault injection so that a potentially infrequently "missed upgrade" > path can be exercised easily. Perhaps with a kernel config option or > that fault injection stuff? > > just some ideas. > > Maybe there's someone that can explain how IBM does the rwlocks. IBM's method is documented online: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=%2Fapis%2Fconcep26.htm However, I think these semantics are horrible. Others may disagree. > Why do we want to have our own method. And if our methods are different, > does it break the semantics that may become standard across the board? Does it > help us to diverge? What about OS X and Solaris? I am mostly asking to see if anyone else knows of alternate semantics to that of IBM's. I would rather not do the IBM semantics if possible because as I stated above, I think they are non-obvious and non-intuitive. I was not able to find any references online to any other pthread implementations that support upgrades or downgrades on rwlocks however. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Tue Jan 25 15:35:52 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79D041065672; Tue, 25 Jan 2011 15:35:52 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 307938FC16; Tue, 25 Jan 2011 15:35:51 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 7D3921A3C3F; Tue, 25 Jan 2011 07:35:51 -0800 (PST) Date: Tue, 25 Jan 2011 07:35:51 -0800 From: Alfred Perlstein To: John Baldwin Message-ID: <20110125153551.GR21872@elvis.mu.org> References: <201101241604.21451.jhb@freebsd.org> <20110125011839.GK21872@elvis.mu.org> <201101250915.38937.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201101250915.38937.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: threads@freebsd.org, David Xu Subject: Re: Try upgrades and downgrades for POSIX rwlocks X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 15:35:52 -0000 * John Baldwin [110125 06:21] wrote: > On Monday, January 24, 2011 8:18:39 pm Alfred Perlstein wrote: > > * John Baldwin [110124 13:05] wrote: > > > Does anyone know if there is a de facto or proposed standard for supporting > > > upgrades and downgrades in POSIX rwlocks? IBM seems to support something > > > rather gross where a wrlock() will succeed if the only shared lock is held by > > > the current thread. But then the thread holds both a read and write lock, and > > > it has to call unlock twice, the first to drop the write lock, the second to > > > drop the read lock. If we were to add support for upgrades and downgrades I > > > would prefer something more along the lines of our in-kernel APIs where there > > > are try_upgrade() and downgrade() operations that convert a given lock between > > > states. > > > > There may a be a tricky problem here. > > > > In order to avoid writer starvation (in the kernel) we give writers > > preference over readers so that many concurrent readers can't keep > > the lock in a shared-only state forever. (Or at least that's how I > > left it when I touched it last. :D ) > > > > There is a problem here. > > > > To conserve that behavior we need to look at the situation of an upgrade: > > 1) we have to put the upgrader to the front of the writer queue, > > this can starve other threads looking for only a writer lock by > > giving an unfair advantage to those that take a share lock first. > > > > 2) we don't even look at this issue and we wind up with some deadlock. > > > > At a glance, I think we have to have some kind of "try_upgrade" > > that doesn't give preference to the thread already holding the lock. > > Err, I generally think try_upgrades (which by nature give preference to the > current thread since they only succeed if the only shared lock held is that > of the current thread) are the only "sane" upgrade operation. If you have > any sort of blocking upgrade then you have to handle the problem of two > concurrent upgrades in which case at least one upgrade would only be able > to succeed after another thread has obtained a write lock and modified the > state, and I suspect most programmers don't realize that after a blocking > lock upgrade they cannot trust any of the state that they checked under > the read lock and instead need to recheck all of that. Having a try_upgrade > forces them to handle this since it can fail and in the failure case it is > more obvious that you have to reexamine state if you fall back to doing a > read lock followed by a blocking write lock. Agreed 100%. > > > We should probably strongly encourage try_upgrades to have some sort > > of fault injection so that a potentially infrequently "missed upgrade" > > path can be exercised easily. Perhaps with a kernel config option or > > that fault injection stuff? > > > > just some ideas. > > > > Maybe there's someone that can explain how IBM does the rwlocks. > > IBM's method is documented online: > > http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=%2Fapis%2Fconcep26.htm > > However, I think these semantics are horrible. Others may disagree. They do raise an eyebrow... the way that unlocks are handled are really nasty. > > > Why do we want to have our own method. And if our methods are different, > > does it break the semantics that may become standard across the board? Does it > > help us to diverge? What about OS X and Solaris? > > I am mostly asking to see if anyone else knows of alternate semantics to that > of IBM's. I would rather not do the IBM semantics if possible because as I > stated above, I think they are non-obvious and non-intuitive. I was not able > to find any references online to any other pthread implementations that > support upgrades or downgrades on rwlocks however. No idea. -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-threads@FreeBSD.ORG Tue Jan 25 16:09:06 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5CAB106564A; Tue, 25 Jan 2011 16:09:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8C5418FC18; Tue, 25 Jan 2011 16:09:06 +0000 (UTC) Received: by gxk8 with SMTP id 8so1852639gxk.13 for ; Tue, 25 Jan 2011 08:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2aXX9jewzG7VifrqCoglnutMxEuQVN7iaSJKO70ZAz0=; b=iq1qnhRk2ohkG116NAV0AREr4AWMSmqpyxPQ/NlTk4vX7kXn4ncUc0WgLxuVOflDgV RlffZoC/V45sNX/NidA+mzYVV037ixP9DLTyKyvFyhgcuZfVHEOvU78QgHPSnObsAFWq gAdXN0Np/igTzvMMoctFdJyTjZW9P1Vq3gRRo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ElKyXpt7vKeAo5rn/+PifEyPCzK3elLoPH9/MIUuTeRWqdw5WajGAP0cc9/tErQSyN zk+Qckr7E15nJoSEOm3kPKc+Q7pYX3JYHm6AhfdQZrIcOgNY3L4Jbg6qXQJWrSkgIHw+ wqFRCr+I75sSxZNYrd3d01WlIzlWauxxp+lzI= MIME-Version: 1.0 Received: by 10.100.136.2 with SMTP id j2mr496656and.139.1295970007059; Tue, 25 Jan 2011 07:40:07 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.236.108.15 with HTTP; Tue, 25 Jan 2011 07:40:07 -0800 (PST) In-Reply-To: <201101241604.21451.jhb@freebsd.org> References: <201101241604.21451.jhb@freebsd.org> Date: Tue, 25 Jan 2011 16:40:07 +0100 X-Google-Sender-Auth: NhRAtb2GKWjOaOmygdSrDl04aBo Message-ID: From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: threads@freebsd.org, David Xu Subject: Re: Try upgrades and downgrades for POSIX rwlocks X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:09:07 -0000 2011/1/24 John Baldwin : > Does anyone know if there is a de facto or proposed standard for supporti= ng > upgrades and downgrades in POSIX rwlocks? =C2=A0IBM seems to support some= thing > rather gross where a wrlock() will succeed if the only shared lock is hel= d by > the current thread. =C2=A0But then the thread holds both a read and write= lock, and > it has to call unlock twice, the first to drop the write lock, the second= to > drop the read lock. =C2=A0If we were to add support for upgrades and down= grades I > would prefer something more along the lines of our in-kernel APIs where t= here > are try_upgrade() and downgrade() operations that convert a given lock be= tween > states. I'd support us adopting the same semantic rwlock in kernel space have. An alternative semantic would be what lockmgrs do: - try to upgrade - if failed (more than one shared owner then): * drop our shared lock * try a normal exclusive acquisition That seems like more linear, even if I'm very much more in favor of not having something like that (infact, removing LK_UPGRADE is one of my personal target, as such operation can be implemented in consumers themselves as well, if they want). Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-threads@FreeBSD.ORG Tue Jan 25 16:17:13 2011 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E041106566B; Tue, 25 Jan 2011 16:17:13 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id D3D1B8FC0A; Tue, 25 Jan 2011 16:17:12 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 23A661A3C3F; Tue, 25 Jan 2011 08:17:12 -0800 (PST) Date: Tue, 25 Jan 2011 08:17:11 -0800 From: Alfred Perlstein To: Attilio Rao Message-ID: <20110125161711.GT21872@elvis.mu.org> References: <201101241604.21451.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: threads@freebsd.org, David Xu Subject: Re: Try upgrades and downgrades for POSIX rwlocks X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 16:17:13 -0000 * Attilio Rao [110125 08:09] wrote: > 2011/1/24 John Baldwin : > > Does anyone know if there is a de facto or proposed standard for supporting > > upgrades and downgrades in POSIX rwlocks? ??IBM seems to support something > > rather gross where a wrlock() will succeed if the only shared lock is held by > > the current thread. ??But then the thread holds both a read and write lock, and > > it has to call unlock twice, the first to drop the write lock, the second to > > drop the read lock. ??If we were to add support for upgrades and downgrades I > > would prefer something more along the lines of our in-kernel APIs where there > > are try_upgrade() and downgrade() operations that convert a given lock between > > states. > > I'd support us adopting the same semantic rwlock in kernel space have. > An alternative semantic would be what lockmgrs do: > - try to upgrade > - if failed (more than one shared owner then): > * drop our shared lock > * try a normal exclusive acquisition > > That seems like more linear, even if I'm very much more in favor of > not having something like that (infact, removing LK_UPGRADE is one of > my personal target, as such operation can be implemented in consumers > themselves as well, if they want). In my opinion the implicit drop semantic is really an error prone API and makes the code hard to read. I agree the LK_UPGRADE stuff is scary. -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer