# Thread switching? (p. 144 pickaxe2)

**URL:** <https://www.ruby-forum.com/t/thread-switching-p-144-pickaxe2/115053>\
**Category:** Ruby\
**Created:** [September 20, 2007, 6:19am UTC](https://www.ruby-forum.com/t/thread-switching-p-144-pickaxe2/115053 "2007-09-20T06:19:25Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![7stud](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/7/57b2e6/32.png) [@7stud](https://www.ruby-forum.com/u/7stud)\
**Post date:** [September 20, 2007, 6:19am UTC](https://www.ruby-forum.com/t/thread-switching-p-144-pickaxe2/115053/1 "2007-09-20T06:19:25Z")

</div>

Hi,

On p. 144 in pickaxe2, there are two examples using threads(see below).  
Each thread updates a counter, and the function call that updates the  
counter is synchronized to prevent simultaneous axis to the counter.  
Presumably, one thread doesn’t update the counter 100,000 times,  
followed by the other thread updating the counter 100,000 times–that  
wouldn’t execute anything simultaneously, which is the whole point of  
threads. Therefore, it seems reasonable to assume that execution  
switches between the threads. In fact, there is a table on p. 143 that  
illustrates what happens when thread switching occurs in the  
unsynchronized case.

But on p. 145, there is an example that creates two threads: a producer  
thread and a consumer thread. The consumer thread is regularly put to  
sleep while it awaits data from the producer thread, which I assume  
would cause execution to switch to the producer thread. However, the  
text explains cryptically,

“But because _we_ own the monitor, the [producer thread] will never be  
able to enter its synchronization block, and will never add something to  
the playlist.”

First of all, as far as I can tell, I’m the only one in the room reading  
the book; there is no "we’. Second of all, I have never and will never  
own a monitor object. What kind of description is that? Is pickaxe2 a  
children’s book about bears eating porridge or something? Maybe in  
future versions the author could use a more professional writing style?

In any case, why doesn’t thread switching happen in the example on p.  
145:

playlist = []  
playlist.extend(MonitorMixin)

#Player thread  
Thread.new do  
record = nil  
loop do  
puts “\*”  
playlist.synchronize do  
sleep 0.1 while playlist.empty?  
record = playlist.shift  
end  
puts record  
end  
end

#Customer request thread  
Thread.new do  
loop do  
puts “-”  
playlist.synchronize do  
playlist \<\< “hello”  
end  
end  
end

and why is the output:

- 

- 

…yet thread switching does occur in the example on p. 144:

require “monitor”

class Counter  
attr\_reader :count

```
def initialize
    @count = 0
end
def tick
    @count += 1
end

```

end

c = Counter.new  
lock = Monitor.new

t1 = Thread.new do  
100\_000.times do  
lock.synchronize do  
c.tick  
end  
end  
end

t2 = Thread.new do  
100\_000.times do  
lock.synchronize do  
c.tick  
end  
end  
end

t1.join  
t2.join

puts c.count

---

<div class="post-metadata">

**Author:** ![7stud](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/7/57b2e6/32.png) [@7stud](https://www.ruby-forum.com/u/7stud)\
**Post date:** [September 20, 2007, 12:24pm UTC](https://www.ruby-forum.com/t/thread-switching-p-144-pickaxe2/115053/2 "2007-09-20T12:24:48Z")

</div>

On Sep 20, 2007, at 12:19 AM, 7stud – wrote:

> On p. 144 in pickaxe2, there are two examples using threads(see  
> below).  
> Each thread updates a counter, and the function call that updates the  
> counter is synchronized to prevent simultaneous axis to the counter.

Since you are picky enough to complain about the writing in Pickaxe  
2, I feel justified in pointing out that your “axis” should be “access”.

> In any case, why doesn’t thread switching happen in the example on p.  
> 145:

There are two problems with this code.

> playlist = []  
> playlist.extend(MonitorMixin)
> 
> #Player thread  
> Thread.new do  
> record = nil  
> loop do  
> puts “\*”  
> playlist.synchronize do

1. The “while playlist.empty?” causes deadlock.

> ```
> puts "-"
> playlist.synchronize do
> playlist << "hello"
> end
> end
> 
> ```
> 
> end

1. The main thread exits immediately killing both child threads.

The following will run for 2 seconds before dying.

`
#! /usr/bin/env ruby -w
require “monitor”
playlist = []
playlist.extend(MonitorMixin)
pending = playlist.new_cond
Thread.abort_on_exception = true
Thread.new do
record = ‘none’
loop do
puts “*”
playlist.synchronize do
pending.wait_while { playlist.empty? }
record = playlist.shift
end
p record
end
end
Thread.new do
loop do
puts “-”
playlist.synchronize do
sleep 0.5
playlist << “hello”
pending.signal
end
p playlist
end
end
sleep 2
`

Regards, Morton