Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.ruby > #7076

Re: multithreading best practice

Show all headers | View raw

Good evening.

Thank you for the responses, so far.

On Sun, 11 Jan 2015 17:58:17 +0100,
Robert Klemme <shortcutter@googlemail.com> wrote:
> On 11.01.2015 17:17, Michael Uplawski wrote:
>
>> 2.) Origin.
(...)
>> 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.

You are right, as regards the pieces of information that I considered
sufficient for my problem description. The current file-size will be
marshalled together with other (... remember Marshal?) information to
construct a list of queued download-items. Using the authentic
file-size, instead, to document the download progress, may be a
solution. 

I admit, though, that the synchronization effort that I describe, is
hypothetical. As you and Doc O'Leary have noticed, it is not really
needed in the context of my current fun-project (see my comment on the
Mutex, quoted above). 

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

This is where my headache started.

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

So, basically, if I understand you correctly, the Mutex is used in one
thread only, but there secures all access to the variable (or critical
section). I see, that “the other” thread, in this case does not need,
neither the Mutex, nor the *original* variable.

I have not yet thought in this way and hope that I've got it right.

TY,

Michael
> Kind regards
>
> 	robert
>
>


-- 
GnuPG/OpenPGP  4096R/3216CF02 2013-11-15 [expires: 2015-11-15]
sub   4096R/2751C550 2013-11-15 [expires: 2015-11-15]

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