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

Groups > comp.lang.ruby > #7077

Re: multithreading best practice

Show all headers | View raw

On 11.01.2015 19:20, Michael Uplawski wrote:
> Good evening.
>
> Thank you for the responses, so far.

You're welcome.

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

Redundancy always causes trouble, so I think this is better.

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

No.  All threads that want to access the size must go through the mutex:
https://gist.github.com/rklemme/10f36380ab5899911b5d

Cheers

	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