Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Andrew Reilly Newsgroups: comp.arch Subject: Re: Single Thread Performance Date: 14 Feb 2012 10:49:14 GMT Lines: 22 Message-ID: <9push9Ft0mU1@mid.individual.net> References: <18985540.1742.1328921030856.JavaMail.geo-discussion-forums@yqks7> <4F38875A.2050407@SPAM.comp-arch.net> <12562993.824.1329107776365.JavaMail.geo-discussion-forums@ynnj2> <4F392235.1020804@SPAM.comp-arch.net> <16314332.739.1329152301273.JavaMail.geo-discussion-forums@ynnk21> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net 8kokYxKsQBHYPNUWLXd1DwJsgT8kIotfKqcnZmtGgwtRAZpRUG Cancel-Lock: sha1:bpH761d2RWc85vVJH6bkY824Vjw= User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Xref: x330-a1.tempe.blueboxinc.net comp.arch:5927 On Tue, 14 Feb 2012 10:30:05 +0100, Terje Mathisen wrote: > This would correspond to having a similar exponential wait in every busy > loop retrying a lock, everyone accessing the lock using the same > algorithm. This is not going to happen. :-( Isn't it? I was under the impression that lock contention was a single- process phenomon, which is essentially the prerequisite for having control over that sort of thing. Surely the only thing between this happening and the current situation is a successful library that does this by default? Given the success of Ethernet, I am quite surprised that the same approach doesn't seem to be common or popular for lock contention. Perhaps because there are still many different use scenarios, and the fact that operating systems aren't famously good at reliable short time- outs. Cheers, -- Andrew