Re: multithreading best practice

From	Robert Klemme <shortcutter@googlemail.com>
Newsgroups	comp.lang.ruby
Subject	Re: multithreading best practice
Date	2015-01-11 18:02 +0100
Message-ID	<chfol3F9n1pU1@mid.individual.net> (permalink)
References	<slrnmb58gv.2co.michael.uplawski@drusus.uplawski.eu> <chfodbF9mc9U1@mid.individual.net>

Show all headers | View raw

On 11.01.2015 17:58, Robert Klemme wrote:
> 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.

PS: You may also want to use file locking to avoid two downloads 
appending to the same file at the same time.

http://www.ruby-doc.org/core-2.2.0/File.html#method-i-flock


-- 
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