From: Matthew Kerwin Date: 2012-12-31T08:24:09+09:00 Subject: Re: Thread.start(variables) do question --047d7b2e46185cf29b04d21a30ef Content-Type: text/plain; charset=ISO-8859-1 7stud -- wrote: > Matthew Kerwin wrote in post #1090641: > > > > Thought of one (sorry for replying to myself): > > > > a = 1 > > loop do > > Thread.new { b=a; p b } > > a += 1 > > end > > > > .. where `a += 1` is likely to run before `b=a`; > > What makes you think that? Experience in multithreaded environments. Without an explicit mutex or other locking mechanism (or call to Thread#join) there's no guarantee that either will run before the other. I know that in MRI the GVL is a large player, but I'm not being implementation-specific here. If I really had to guess, in a truly parallel multithreaded environment, assuming that the block begins execution at the same instant as the line after Thread.new, I'd guess that the `b=a` operation would happen before the `a = ...`, assuming that `a += 1` is actually broken down into `a = a + 1` which has an extra operation and so should take longer. However in a less parallel system I would have assumed the current thread would execute a bit before the child thread was given some CPU time, so `a += 1` would have a chance to complete before `b=a`. In either case it's something over which I as the programmer do not have any control. Matma Rex wrote: > There's another thing apart from the race conditions. These are mostly equivalent (except for what you've already said) only if there is no variable called `b` in the outer scope - if there was one, in your second example `b=a` will assign to it and change the value outside the thread. In the first case, the "outer" `b` will simple be inaccessible inside the thread, but its value outside the thread won't be changed. Ah, that's a really good point. I'd forgotten that 1.9 masks variables with the same name as block parameters. Now that you've said it, I remember having to refactor a bunch of OptParse code that used to use: on('-x', Integer, 'foobar') {|$x| } -- Matthew Kerwin, B.Sc (CompSci) (Hons) http://matthew.kerwin.net.au/ ABN: 59-013-727-651 "You'll never find a programming language that frees you from the burden of clarifying your ideas." - xkcd --047d7b2e46185cf29b04d21a30ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
7stud -- <lists@ruby-forum.com> wrote:
Matthew Kerwin wrote in post #1090641:
>
> Thought of one (sorry for replying to myself):
>
> =A0 =A0 a =3D 1
> =A0 =A0 loop do
> =A0 =A0 =A0 Thread.new { b=3Da; p b }
> =A0 =A0 =A0 a +=3D 1
> =A0 =A0 end
>
> .. where `a +=3D 1` is likely to run before `b=3Da`;

What makes you think that?

Expe= rience in multithreaded environments. Without an explicit mutex or other lo= cking mechanism (or call to Thread#join) there's no guarantee that eith= er will run before the other. =A0I know that in MRI the GVL is a large play= er, but I'm not being implementation-specific here.

If I really had to guess, in a truly parall= el multithreaded environment, assuming that the block begins execution at t= he same instant as the line after Thread.new, I'd guess that the `b=3Da= ` operation would happen before the `a =3D ...`, assuming that `a +=3D 1` i= s actually broken down into `a =3D a + 1` which has an extra operation and = so should take longer. However in a less parallel system I would have assum= ed the current thread would execute a bit before the child thread was given= some CPU time, so `a +=3D 1` would have a chance to complete before `b=3Da= `. In either case it's something over which I as the programmer do not = have any control.

Matma Rex=A0<matma.rex@gmail.com> wrote:
> Ther= e's another thing apart from the race conditions. These are mostly equi= valent (except for what you've already said) only if there is no variab= le called `b` in the outer scope - if there was one, in your second example= `b=3Da` will assign to it and change the value outside the thread. In the = first case, the "outer" `b` will simple be inaccessible inside th= e thread, but its value outside the thread won't be changed.

Ah, that's a really good point. I'd forgo= tten that 1.9 masks variables with the same name as block parameters. Now t= hat you've said it, I remember having to refactor a bunch of OptParse c= ode that used to use:

=A0 =A0 on('-x', Integer, 'foob= ar') {|$x| }

--
=A0 Matthew Kerwin, B.Sc (CompS= ci) (Hons)
=A0 http://matthew.kerwin.net.au/
=A0 ABN: 59-013-727-651

=A0 "You'll never find a programmin= g language that frees
=A0 you from the burden of clarifying your ideas.&= quot; - xkcd
--047d7b2e46185cf29b04d21a30ef--