Race conditions?

[MegaFPyKT]

Hello. Sorry for my english, but tell me please. This is normal behavior?

def test(i) 
sleep(1)
return i
end

def test1()
g=[]
pool = Concurrent::FixedThreadPool.new(20)
 for i in 1..5 do
      pool.post do
      g[i]=test(i)   
      end
 end
sleep 5
p g
end
test1()

Result:
[nil, nil, nil, 3, nil, 5]
or
[nil, nil, nil, nil, 4, 5]
or
[nil, nil, 2, 3, nil, nil]

If I add a "sleep()"

 def test(i)
sleep(1)
return i
end

def test1()
g=[]
pool = Concurrent::FixedThreadPool.new(20)
 for i in 1..5 do
     sleep(0.1)
      pool.post do
      g[i]=test(i)   
      end
 end
sleep 5
p g
end
test1()

Result:
[nil, nil, 2, 3, 4, 5]

---

• Operating system: linux
• concurrent-ruby version: 1.0.3
• concurrent-ruby-ext installed: yes / no
• concurrent-ruby-edge used: yes / no

[pitr-ch]

Could you please reformat the code and use "```ruby" to enable highlighting? It's hard to read.

[jdantonio]

The issue isn't with the thread pool, it's with the use of the loop control variable within the posted job. You are pulling a variable from the closure which changes while the operations are in progress. The correct code looks like this:

  for index in 0..4 do
    pool.post(index) do |i|
      g[i]=test(i)
    end
  end

In this version we pass the value of the loop control variable into the #post method. This captures the value at the moment it is passed. The code now gives the result you were hoping to see:

[0, 1, 2, 3, 4]

Please note that Ruby arrays are zero-based so I changed the loop from 1..5 to 0..4.

[pitr-ch]

Thanks @jdantonio for the answer.

[eregon]

Just as a note, this is an unfortunate side-effet of how for works, by hoisting the variable declaration in the same scope as the for:

a1 = []
for i in 1..5 do
  a1 << -> { i }
end
p a1.map(&:call) # => [5, 5, 5, 5, 5]

a2 = []
(1..5).each do |i|
  a2 << -> { i }
end
p a2.map(&:call) # => [1, 2, 3, 4, 5]

So changing the for with (0..4).each do |i| above also fixes the problem.