Thanks for the comments about atomicity vs. thread-safety. Absolutely on point. The article started out demonstrating what happened with concurrent Array mutation, but then I put in that += operation and didn't address it. Sorry for not making the distinction. Atomicity is absolutely a different issue than a thread-safe collection. I'm publishing something new tomorrow that addresses this point.
To bring things back to code, the point I was originally trying to make is that this code is not thread-safe.
array = []
threads = []
10.times do
threads << Thread.new do
100.times { array.push(rand) }
end
end
threads.each(&:join)
# 10 threads each inserted 100 values, result should be 1000
puts array.size
Specifically, too many Ruby programmers won't think twice about this operation not being thread-safe:
array.push(item)
But there's no such guarantee. This is demonstrated nicely when this code example is run on an implementation with no global lock, try it on JRuby.
There are some very specific caveats that MRI makes for concurrent IO. If you have one thread that's waiting on IO (ie. waiting for a response from the DB or a web request), MRI will allow another thread to run in parallel.
AFAIK there is no spec. MRI is the reference implementation, but many things are experimental or intentionally unspecified.
Given that MRI ships with a GIL, the only core classes that are intentionally aware of multi-threading concerns are Mutex, ConditionVariable, and Queue.
A GIL does not mean classes should ignore concurrency concerns, it's still possible to get odd behaviour from things like hash table implementations in a GIL based interpreter when inserting objects as you may end up thread switching mid operation.
What saves you most of the time is that it isn't worth switching threads too often so normally you get lucky.
Even a thread-aware collection where collection methods are synchronized on an internal lock (as in Java 1.0 — this was quickly dropped as it's effectively useless) wouldn't help here: having `[]` and `[]=` safe will not make calling `[]`, performing an addition and then calling `[]=` safe.
Before Pat announced he was writing an ebook, I was following the articles he wrote on his blog. He has a real knack for making difficult concepts easy to understand using diagrams and simple language. And on top of that, he asks interesting questions. You might think that Ruby internals are a dull topic, but everything I've seen him cover has fascinated me.
Because I've already learned so much from this articles, I was eager to buy this when I saw the announcement in my inbox.
I would. There really wasn't much 'bother' to speak of once I understood how it worked. And even though it wasn't as fruitful as other efforts, many small returns add up quickly.
I'll be interested to hear how the print edition works out. So many things are different between the various ebook deals and their markets and the printed book deals and their markets.
346 hours is both an underestimation and an overestimation. I can say that I definitely did not sit down at the keyboard for 346 hours to put this together. But how do you account for time spent thinking about the content, planning, visualizing, etc? What about the fact that most of that time was 'overtime'? ie. over and above my full-time job.
The other perspective here is that this took a lifetime of work. I've been learning about the source material for the past several years. Obviously it wasn't just to write this book, it has many practical applications besides. I've 'practiced' teaching people and writing for years before this, all of that certainly contributed. This quote sums it up nicely: http://www.marketingquoteoftheday.com/pablo-picasso-on-prici....
I don't think it's fair to try to trim down a project like this to an hourly rate because it simply doesn't work like that. I could stop putting time and effort into the project right now and I would still see some money come in, arbitrarily increasing that hourly rate.
Just to drive home this point having a book with my name on it opens up new opportunities. If I were to write another book and spend the exact same amount of time putting it together my 'hourly rate' would probably increase because I now have more people listening to what I have to say and trusting that I will provide something of value. So investing time now into this project is a long-term investment that I may not make back on the sales of this book, if you know what I mean.
I've no idea if it's feasible to write like this for a living. There are lots of people (even in the tech education space) who make a living selling their own products, but typically not just books. Look at people like Marc-Andre Cournoyer or Peter Cooper who have written books but make their living through some combination of teaching mediums (video, webinar, books, training, etc). For many of them their first product was an ebook.
Just to clean things up, this book was written out of love. I felt like I couldn't not write this book once the inspiration came. That being said, there was also a financial motive. I wanted to be compensated for my work, but also wanted other people to place value on the material. Too often free material is considered worthless because there was no exchange made for it. "If you don't give anything you don't get anything", so to speak.
