Re: multithreading best practice

Path	csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From	Robert Klemme <shortcutter@googlemail.com>
Newsgroups	comp.lang.ruby
Subject	Re: multithreading best practice
Date	Sun, 11 Jan 2015 17:58:17 +0100
Lines	43
Message-ID	<chfodbF9mc9U1@mid.individual.net> (permalink)
References	<slrnmb58gv.2co.michael.uplawski@drusus.uplawski.eu>
Mime-Version	1.0
Content-Type	text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding	7bit
X-Trace	individual.net crVmjGWmayGI1KomsvDcqgGpPftPEql5P8RjhVjnT3VUsomnU=
Cancel-Lock	sha1:jM/vx9eqLdBGYRavAl8HGYd6Ay4=
User-Agent	Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
In-Reply-To	<slrnmb58gv.2co.michael.uplawski@drusus.uplawski.eu>
Xref	csiph.com comp.lang.ruby:7072

Show key headers only | View raw

On 11.01.2015 17:17, Michael Uplawski wrote:

> 2.) Origin.
> I locate the problem there, where a mutex protects the variable which
> holds the current file-size, or the position, where new data has to be
> added. It looks like a chunk of downloaded data is added to the file,
> but then, while showing the current file-size on screen, the variable
> cannot be updated. *If* the download is interrupted just there, the
> range-header in my http-request holds the wrong number and the
> http-server will serve once again the last successfully received chunk
> of data. The Mutex is superfluous, as I have recognized. Ignore it, I
> have removed it.
>
> 3.) Question:
> Let's assume, the current file-size *had to be protected* by a Mutex,
> because two threads try at some time or other to alter its value.
> How would you do it. Are thread-priorities enough, or do I have to
> observe the length of sleep() pauses to ensure that no errors happen?

First of all I do not understand why you need to have the file size in a 
variable in memory.  The filesystem will always provide the current 
filesize correctly.

Then, if you duplicate the file size in memory what you need seems to be 
more complex than a mutex: you need a mechanism that ensures only on 
thread (the downloading thread) is allowed to update the value while any 
other thread is allowed to read the current value.  a ReadWriteLock 
won't do because if you keep the write lock engaged while the download 
progresses nobody can read it.  You could use a mutex and a data 
structure which stores a reference to the downloading thread - possibly 
in a WeakReference.  Then access that data structure only through the 
mutex for reading of the current size as well as updating the size. 
This mutex is short lived, i.e. it will not be held while showing the 
size on the screen, only for fetching the current value.

Kind regards

	robert

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

Back to comp.lang.ruby | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

multithreading best practice Michael Uplawski <michael.uplawski@uplawski.eu> - 2015-01-11 17:17 +0100
  Re: multithreading best practice Robert Klemme <shortcutter@googlemail.com> - 2015-01-11 17:58 +0100
    Re: multithreading best practice Robert Klemme <shortcutter@googlemail.com> - 2015-01-11 18:02 +0100
      Re: multithreading best practice Michael Uplawski <michael.uplawski@uplawski.eu> - 2015-01-11 19:22 +0100
    Re: multithreading best practice Michael Uplawski <michael.uplawski@uplawski.eu> - 2015-01-11 19:20 +0100
      Re: multithreading best practice Robert Klemme <shortcutter@googlemail.com> - 2015-01-11 22:55 +0100
        Re: multithreading best practice Michael Uplawski <michael.uplawski@uplawski.eu> - 2015-01-13 09:03 +0100
          Re: multithreading best practice Robert Klemme <shortcutter@googlemail.com> - 2015-01-14 22:37 +0100
            [OT] Response to Robert Klemme [Was: multithreading best practice] Michael Uplawski <michael.uplawski@uplawski.eu> - 2015-01-15 13:32 +0100

csiph-web