Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Library for Escalable Locks, Slimmest API? Date: Sat, 13 Aug 2016 11:08:38 +0200 Lines: 32 Message-ID: References: <26c75c11-5955-45a6-919d-3de1255c9c15@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net wxzrDyiAge4PtulREsVA5Q83Mh0em3FJTx9hAGmdJkbp3lwLQ= Cancel-Lock: sha1:z9ojE4CzDTZ2aiR8I4WEv6yvtkI= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:35295 On 13.08.2016 07:56, Andreas Leitgeb wrote: > Robert Klemme wrote: >> How do you harden something that inherently comes with the potential for >> deadlock? > > Easy: just turn the potential into a guarantee. > > That would make it pretty *hard* to make a working > multithreaded application, wouldn't it? I had not thought of that option. While we are at it, I remember an anecdote from quite some time ago: that was with a multithreaded application that accessed a relational database. At some point processing came to a halt. No CPU consumption, no IO, no GC - it looked like a deadlock. But then the RDMBs at hand had deadlock detection so whenever two transactions were interlocked one would be automatically rolled back with an error. This did not happen. It took us a while to figure that the deadlock was actually created via one resource in the database and one resource in application memory: the two involved threads acquired exclusive locks on these in different order and the database as well as the JVM were each only aware of one resource, so no automatic deadlock detection. That was a valuable lesson. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/