Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: KitKat Newsgroups: comp.lang.java.programmer Subject: Re: Why "lock" functionality is introduced for all the objects? Date: Thu, 30 Jun 2011 18:29:23 -0400 Organization: Nestle Lines: 23 Message-ID: References: NNTP-Posting-Host: sVU5oalDgoYYKaoZo9xviQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: WinVN 0.99.12z (x86 32bit) X-Notice: Filtered by postfilter v. 0.8.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5801 On 30/06/2011 6:04 PM, Tom Anderson wrote: > What happened then was that a very clever chap called David Bacon, who > worked for IBM, invented a thing called a thin lock: > > http://www.research.ibm.com/people/d/dfb/papers.html#Bacon98Thin > > Which was subsequently improved by another clever chap called Tamiya > Onodera into a thing called a tasuki lock, which you don't hear so much > about. Are you sure that last one was a "chap"? "Tamiya" sounds rather feminine to me. > The details are described quite clearly in the papers, but the upshot is > that an object is created with neither a lock nor a slot for a lock > pointer (and so only a two-word header), and the lock is allocated only > when needed, and then wired in. Some fancy footwork means that the > object doesn't need to grow a pointer when this happens; the header > remains two words, at the expense of some slight awkwardness elsewhere. Such as? I can think of only one possibility that could be even close to efficient: maintain an IdentityHashMap somewhere under the hood.