Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Robert Klemme <shortcutter@googlemail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Library for Escalable Locks, Slimmest API?
Date: Sun, 14 Aug 2016 14:29:33 +0200
Lines: 72
Message-ID: <e1b6heFespjU1@mid.individual.net>
References: <no7p5p$11i$1@news.albasani.net> <slrnnqfmvf.456.avl@login.logic.tuwien.ac.at> <no9cu2$1pl$1@news.albasani.net> <slrnnqmf45.456.avl@login.logic.tuwien.ac.at> <nofjbk$sgd$1@news.albasani.net> <26c75c11-5955-45a6-919d-3de1255c9c15@googlegroups.com> <nohksl$lsj$1@news.albasani.net> <e16p89FdmcoU1@mid.individual.net> <nompol$fqt$1@news.albasani.net> <e19h9vF37j0U1@mid.individual.net> <nopee6$efa$1@news.albasani.net> <e1auj7Fcvt6U1@mid.individual.net> <noplku$rru$1@news.albasani.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net atxNhl6I6flx+Yhk/utlfgsLhKn2GBoC/0cRcCi/bJK74thuM=
Cancel-Lock: sha1:i5J6ZQaKEKhUHHPFMw6YcqAk8Zo=
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
In-Reply-To: <noplku$rru$1@news.albasani.net>
Xref: csiph.com comp.lang.java.programmer:35340

On 14.08.2016 13:45, j4n bur53 wrote:
> Robert Klemme schrieb:
>> resourceNeedsLoading() could then either check whether the resource has
>> been loaded at all or also include modified time checks on the file.
>
> No I don't have a dedicated load thread.
>
> Yes it might happen that two threads try to read the
> same resource at the same moment.
>
> The write lock is used to serialize the read and update
> of the resource, and a modified time check is used to
> avoid a double read.
>
> There are still issues here. Since before the resource
> content is updated, both threads might already have
> a reader handle and thus a modified time.
>
> I recently moved getting the reader handle outside
> of the write lock block. Maybe this is not a good
> idea. Have to work on this also.
>
> So its not exactly:
>
>   acquire w-l
>   if ( resourceNeedsLoading() ) {
>     loadFromFile()
>     updateResource()
>   }
>   release w-l
>
> More along:
>
>   if ( resourceNeedsLoading() ) {
>      acquire w-l
>      loadFromFile()
>      updateResource()
>      release w-l
>   }
>
> But I guess the optimal code is along:
>
>  if ( resourceNeedsLoading() ) {
>     acquire w-l
>     if ( resourceNeedsLoading() ) {
>        loadFromFile()
>        updateResource()
>     }
>     release w-l
>  }

That is not optimal.  That is slow and error prone.  Slow, because you 
call the method for checking at most three times while my code only 
calls it at most two times per execution.  Wrong, because you invoke the 
check method without holding a lock.  That is precisely the reason why 
my suggested code remembers the state when obtained inside the lock and 
reevaluates when holding the read lock.

> I said in the particular case of loading, there
> might be still some slight issues here.

I can confirm that there are issues in your suggestion.

Regards

	robert

PS: Noted some more messages which I haven't yet read.

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/