[concurrency-interest] Improving RWLock compatibility - ownership test

Mostov, Michael (IT) Michael.Mostov@morganstanley.com
Mon, 29 Nov 2004 12:06:32 -0500


This is a multi-part message in MIME format.

------_=_NextPart_001_01C4D635.C67A22A9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello everybody,=20
=20
I am new to the group and apologize if I am raising issue that has been
already discussed. =20
=20
While examining source code of Oswego package, I found that release()
method of RWLocks doesn't check whether caller thread owns the lock.
The lock is always released, even when it was acquired by other thread.
=20
I discussed this feature with a number of people and none of them seemed
to be aware of this behavior.  Finally I sent email to the author, Doug
Lea, and he explained that this check (or it's absence) is not
standardized between various RWLock implementations.  I.e. Oswego
release() doesn't check ownership at all,  while J2SE5 version checks
the ownership for the write lock, but not for read locks.
Usually the decision whether to test the lock ownership or not is driven
by performance considerations, however there are also could be certain
designs that rely on specific behavior.
=20
Hence I suggest to parameterize this behavior by adding an optional
parameter to RWLock constructor.  This will enable compatibility b/n
various lock implementations.   And as an extra benefit, having this
parameter and supporting documentation will raise programmers' awareness
of the somewhat unintuitive behavior.
=20
What do you think?
=20
-Michael=20
--------------------------------------------------------
=20
NOTICE: If received in error, please destroy and notify sender.  Sender =
does not waive confidentiality or privilege, and use is prohibited.=20
=20

------_=_NextPart_001_01C4D635.C67A22A9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<HTML xmlns:eXclaimer=3D"http://www.exclaimer.co.uk">
<HEAD>
<META http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3DUTF-16">
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUTF-16">
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1477" name=3DGENERATOR></HEAD><BODY =
><DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D779112916-29112004>Hello =
everybody,=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D779112916-29112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D779112916-29112004>I am =
new to the=20
group and apologize if&nbsp;I am raising issue that has been already=20
discussed.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D779112916-29112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D779112916-29112004>While =
examining=20
source code of Oswego package, I found that release() method&nbsp;of =
RWLocks=20
doesn't check whether caller thread owns the lock.&nbsp; The lock is =
always=20
released, even when it was acquired by other thread.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D779112916-29112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D779112916-29112004>I =
discussed this=20
feature with a number of people and none of them seemed to be aware of =
this=20
behavior.&nbsp; Finally I sent email to the author, Doug Lea, and he =
explained=20
that this&nbsp;check (or it's absence)&nbsp;is not standardized between =
various=20
RWLock implementations.&nbsp; I.e. Oswego release() doesn't check =
ownership at=20
all,&nbsp;&nbsp;while J2SE5 version checks the ownership for the write =
lock, but=20
not for read locks.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D779112916-29112004>Usually&nbsp;the=20
decision whether to test the lock ownership or not is driven =
by&nbsp;performance=20
considerations, however there are also could be certain designs that =
rely on=20
specific behavior.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D779112916-29112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D779112916-29112004>Hence=20
I&nbsp;suggest&nbsp;to&nbsp;parameterize this behavior by adding an =
optional=20
parameter to RWLock constructor.&nbsp; This will enable compatibility =
b/n=20
various lock implementations.&nbsp;&nbsp;&nbsp;And as an extra=20
benefit</SPAN></FONT><FONT face=3DArial size=3D2><SPAN =
class=3D779112916-29112004>,=20
having this parameter and supporting documentation will raise =
programmers'=20
awareness of the somewhat unintuitive&nbsp;behavior.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D779112916-29112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D779112916-29112004>What =
do you=20
think?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D779112916-29112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D779112916-29112004>-Michael</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D779112916-29112004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D779112916-29112004></SPAN></FONT>&nbsp;</DIV></DIV>
<DIV>
<HR>
</DIV>
<DIV>
<P CLASS=3D"BulletedList" STYLE=3D"MARGIN: 0in 0in 0pt; TEXT-INDENT: =
0in; mso-list: none; tab-stops: .5in"><SPAN STYLE=3D"FONT-SIZE: 8pt; =
COLOR: gray; mso-bidi-font-family: Arial"><FONT FACE=3D"Arial">NOTICE: =
If received in error, please destroy and notify sender.<SPAN =
STYLE=3D"mso-spacerun: yes">  </SPAN>Sender does not waive =
confidentiality or privilege, and use is prohibited.</FONT></SPAN></P>
</DIV></BODY></HTML>

------_=_NextPart_001_01C4D635.C67A22A9--