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: Sun, 14 Aug 2016 13:41:00 +0200 Lines: 40 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 cnbb2MLDlu2P7S5nBYrg9wLC/P9WwFMfOvCkeoYdGMKVq+hqc= Cancel-Lock: sha1:m+ooE/80ntF5tunlPB35AMrdJGs= 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:35330 On 14.08.2016 12:25, j4n bur53 wrote: >> Alternatively the algorithm without any need for lock >> escalation could be like this (pseudo code): > > I need a library where additionaly to that: > > acquire w-l > if ( resourceNeedsLoading() ) { > loadFromFile() > updateResource() > } > release w-l > > Inside loadFromFile() the loading thread can also do an > acquire r-l and then a release r-l. You can do that with Java's ReentrantReadWriteLock: "Additionally, a writer can acquire the read lock, but not vice-versa." But you do not need to because the thread has an exclusive lock already (the write lock) and the write lock excludes read locks. You do not gain anything from that unless you want to do lock downgrading. > Robert Klemme schrieb: >> I do not know though how consistency requirements are in your >> application on a larger scale - especially since you mention >> "re-loading". Under which circumstances is a file reloaded? > > When it has been changed. Well, yes. Then see my suggestion. Regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/