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

Groups > comp.lang.ruby > #7081

Re: multithreading best practice

Show all headers | View raw

On 13.01.2015 09:03, Michael Uplawski wrote:
> On Sun, 11 Jan 2015 22:55:29 +0100,
> Robert Klemme <shortcutter@googlemail.com> wrote:
>> No.  All threads that want to access the size must go through the mutex:
>> https://gist.github.com/rklemme/10f36380ab5899911b5d
>
> Okay. The crucial part is the mandatory check for the identity of the
> thread which is currently in hold of the mutex. Thank you for the nice
> code-example!

Yes, the mutex is used to create a higher level locking structure.

> Looks like a pattern that I have not yet been confronted to. And I
> frequently encounter difficulties, when threads are wrapped in objects.

I don't think it makes sense to talk about threads being "wrapped in 
objects".  In Ruby and Java (and probably elsewhere, too) there are 
classes whose instances represent threads and can be used to manipulate 
threads or query their state.  But the thread of execution only ever 
exists if particular methods are executed which create a new thread.  In 
Ruby this is implicit with the constructor, in Java it's explicit with 
method start().  The thread of execution executes until the main 
function of the thread terminates (in Ruby the anonymous callback passed 
to the constructor, in Java method run()); and this is independent from 
accessibility to the Thread instance!  Conversely the instance does not 
go away, even if the thread of execution terminated.

> Although I have much appreciated this possibility and am familiar with
> different thread classes (from Qt, Java and some project-specific), they
> stay elements of procedural programming in my head...
>
> Thanks for piercing another hole into my limited horizon... ;-)

Just practice - breakthrough will come.  For me it took a while, too.

> Michael, -I am NOT Charlie-, Uplawski

Why not?

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