Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Jumping to false Conclusions [Robert Klemme] (Was: Library for Escalable Locks, Slimmest API?) Date: Sun, 14 Aug 2016 13:45:44 +0200 Lines: 33 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 cQ1Y/cnfrcJ0KNl3YB6w8gtUh862qseXWljfw13n9QEH+12EQ= Cancel-Lock: sha1:VDUJK+umDw70nqH8Yj66UeDy1mY= 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:35332 On 14.08.2016 13:08, j4n bur53 wrote: > Oops, I have to retract my allegations, Thank you. > and I have to work on my memo style presentation. Sometimes terse is too short and more explicit wording helps communication. >> So Robert Klemme(*) jumped to the following conclusions: >> >> larger atomics <=> lower deadlock-freeness I wouldn't know where you took that from. Deadlocks is about locking order. And the fact that a read write lock which allows lock escalation from read to write (better: from shared to exclusive) can _very_ easily deadlock on a single resource. See this answer for an illustration: http://stackoverflow.com/questions/2407558/pthreads-reader-writer-locks-upgrading-read-lock-to-write-lock#answer-2407677 >> But he didn't give some concrete arguments or examples >> for that. I don't believe in the above law. It could >> be even vice versa. see above Regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/