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 23:21:02 +0200 Lines: 38 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 shcOb/NCtRL0VU0GV7jfeAaTMy0zjfEh7D1m7CisXUzdqBW5I= Cancel-Lock: sha1:MPf/kvuTKYvG4K8JQYf9ON0cF/E= 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:35310 On 13.08.2016 11:37, j4n bur53 wrote: > Robert Klemme schrieb: >> How do you harden something that inherently comes with the potential for >> deadlock? > Deadlock-freeness is a property of the application program > that uses parallel components and some synchronization > primitives. Right. But there are lock types with higher and lower likelihood of deadlocks. As far as I can see your lock which allows escalation from shared read to exclusive write is one of the kind with higher likelihood. > I am not the one who writes the application program, I am > only the one who is looking form some synchronization > primitives. In a sense it is worse to provide a library with potential for serious issues than just including such functionality in a particular application. OTOH: > The application I have in mind, is not yet completely written. > I am already using the write locks successfully, but not yet > the read locks as planned. Hardenning the application towards > deadlock-freeness will make no sense, since we cannot > prove deadlock-freeness for the application I have in mind. So are you writing the application or not? Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/