Review: The little book of semaphores by Allen Downey

I’m finally getting round to typing my thoughts on this book up. I read this a little while ago (definitely before the last-merry-holiday period) so am partially using this post as a revision aid.
The plan is to first focus on the book itself and then go a little into how it fits into the larger picture of me playing around with multi-threading.

Review

First off, I have to confess I didn’t finish all of the book. I worked through chapters 1 to 5, skipped 6 and 7 and, finally, skimmed 8 and 9. This is not to say that I didn’t enjoy the book. I think this is a truly great book (and actually pretty clever in the way it is organised too)!

In my mind, the book splits pretty neatly into three parts:

  • Chapters 1 to 3 – Introduction to synchronisation and synchronisation patterns

    In this part, the problem space is introduced (chapters 1 and 2): The start is fairly slow, but things are clearly and carefully explained. Chapter 3 is the key chapter of the book. If you only have time for one chapter, read this one. It introduces useful building blocks for tackling the synchronisation exercises in the following chapters. Beyond this, these are also the conceptual building blocks which one needs to reason about multi-threading problems. Hopefully, this will be useful when thinking through parallelisation problems in practice. (What I particularly like is that the author does not go on and on about the fact that these are design patterns. Normally this kind of things is delivered with a little rah rah rah about the theory behind patterns, etc. Instead he just presents them in an easily accessible way as building blocks for the rest of the book.)

  • Chapters 4 to 7 – Synchronisation problems

    In a sense these chapters are now “just practice exercises”. Yes – some new concepts are introduced (e.g. starvation). However, the focus here is definitely on helping readers critically understand and apply the concepts learnt in chapter 3. The problems are pretty imaginative and are the kind where you can do one on a tube journey with pen and paper (which is what I did). After a while, however, they do get a little repetitive and this is why I “quit” after chapter 5.

  • Chapters 8 & 9 – Synchronisation in practice

    These give a little flavour – not much more than that – of how to execute actual code for the synchronisation problems discussed in the earlier chapters in Python and C. Since I’m currently reading Williams’ C++ Concurrency in Action, which is more relevant for my work with C++, I only gave these a cursory glance. It seems that python multithreaded code is fairly close to the pseudo-code that is used in the rest of the book. For the C code, you’ll need to do a little more leg work. (Oh well….).

In summary, I would really recommend reading this book – in particular – if you are interested in multi-threading concepts and in developing the ability to reason about multi-threaded environments. To enjoy and gain from his book, you do not need a full understanding off the mechanics of a multi-threaded platform. (However, the book also will not give you that understanding.)

How does the book fit into my multi-threading study plan? A summary of things I learnt

The stuff the book covered fits pretty well with the big headline of understanding “multi-threaded concepts in the abstract as well as classical synchronisation problems”. I have a much better understanding of semaphores and their applications:

It’s essentially a mutex with an internal counter which gets decremented every time you call lock/wait and gets incremented every time you call unlock/signal. A thread locks if the counter goes below 0. Every time you call unlock/signal and there are sleeping threads, these will be woken up.

I also have a better understanding of atomics, race conditions, deadlocks, and starvation and how they might come about:

An atomic operation is an operation which cannot be interrupted. From an abstract point of view, it is hard/impossible to tell which high-level operations are actually un-interruptible at a hardware level. The C++ 11 standard deals with this conundrum with introducing atomics as a language facility and a memory model. (This the chapter I’m tackling next in Williams’ concurrency book so the last sentence may not actually make any sense!).

Race conditions occur when the order of execution of the threads influences the output. The classical example is that of two threads incrementing a global variable. Depending on the order of reads & writes, the global variable may end up with a value that is one higher than the start or with a value that is two higher.

A deadlock is the (well known) situation in which a thread cannot proceed because another thread is blocking access to a shared resource. However, the second thread also cannot proceed because the first thread is holding on to a resource which the second thread is looking to acquire before releasing its resource. Neither thread can proceed. (Normally this is described with two threads as above, but it could of course be a problem with multiple threads as in the dining philosopher problem). As far as I can tell, it normally comes about because of the order in which locking is done.

In a starvation scenario, not all threads may be formally locked so there is no deadlock. However, a particular thread may in practice never proceed because it is always overtaken by other threads in a queue and is waiting for them to proceed first. The book describes this in the context of the reader-writer problem where a writer may wait forever.

However, some of the other concepts I mentioned in the study plan post (lock-free programming, condition variables) are covered in much more detail by C++ concurrency in action. I’ll mention those in the review of that book.

Beyond those items that I originally mentioned in the post, I really learnt to appreciate some of the conceptual building blocks of multithreaded code such as:

  • Rendezvous (ensure ordering of statements in two threads)
  • Mutex (ensure only one thread can enter a critical section at a time)
  • Multiplex (ensure only a maximum number of threads can enter a critical section – this is what a semaphore does by default)
  • Barrier (ensure all threads have executed an initialisation before executing a further statement)
  • Turnstile (a wait statement followed by a signal – ensuring that threads pass but can be stopped in front of the turnstile)
  • Reusable barrier (same as the barrier but locking the turnstile after all threads are through)
  • Queues
  • Fifo queues (ensure ordering of threads)
  • Lightswitch (first person in a room turns on the light, last person turns it off. If the light is turned off, a different kind of person ….err… thread may enter. See reader-writers for a better description)
Advertisements

Review: “How Google Tests Software” by James Whittaker, Jason Arbon and Jeff Carollo

(Goodreads link here)

I really wanted to like this book. I did. Unfortunately, the reality is a little bit more complex than that. On the one hand, there are lots of really cool, useful ideas in here. On the other hand, I am not really enamoured with the style. It’s self-congratulatory and at the same time weirdly self-conscious. Finally, I think it tries to do too much in one book.

Let me tackle these points in reverse order (that way we end up with a nice set of useful ideas I picked up right at the end of the post!).

Too much for one book to shoulder

This book tries to do an awful lot. It tries to describe the various roles at Google that testers have. These are the main chapter in the book. Around this structure, it tries to fit in lots of other things: introduce people to the culture of testing at Google, describe software testing techniques (e.g. ACC, test-tours), interview questions and advice, some important projects (e.g. test certification), some tools used during the testing (e.g. Selenium Web-Driver, record-playback tools, ) and a view on the future of testing at Google. Whoa – that is a lot of stuff! And it shows. For me, it really strained the original structure in which everything is meant to fit in. Maybe this is due to me reading the book on the Kindle, but I constantly found myself surprised by the next bit of content, unsure of how things were fitting together. Really good, well thought-through parts were followed by “rather meh” parts.

Altogether, this book is a little bit like an intro course to Google testing, where the instructors try to cram all of the important bits in, and then a couple of important bits more, and then some…

Some notes on style and stuff

Normally, I don’t mind too much about style, but here there are some bits worth pointing out about this book, which I found rather odd: I have not really seen an interview with the author and co-authors itself in a book. It also talks a lot about how Google is leading the way in software testing. In a book about Google’s software testing by Google employees, I think that is a little weird.

Anyway, here are my two cents on Google’s test practices: I think it is worth appreciating that they are leading the way on some levels (e.g. a lot of their tools and some processes/practise look pretty awesome), but on other levels I am not too sure: For example, the division of roles between SWE, SET and TE to me felt artificial (even after a long time in the book is spent justifying it).

Essentially, the process they have gone through is…

  • From a large company where there used to be little enthusiasm for automated testing / unit testing and a traditional division between testers and developers

and transformed this towards a more Agile focussed practice where

  • the roles in the team are much more fluid (i.e. developers take responsibilities for testing) and automated testing is held in high regard

by

  • throwing a large amount of money at the system and using a specialist SET role as a crutch to show “normal developers” the importance of caring about quality

The “future of testing” as they describe it in the last chapter, then, is a future where they can start to throw away the crutch and get rid of the SET role.

The good bits

Enough with the book bashing. I did learn a lot from it after all. Here are the good bits.

  • General spirit

    While I don’t like the tone of the book, I do really like the spirit of the testing culture at Google: Make quality a feature of the main system and make everyone (especially devs) responsible for it. Automate as much of the testing as you possibly can because it scales best.

  • Test certifying a project

    I also like the process of test certification that the book describes (details on this can also be found here): Effectively, it is a way of giving projects within Google a measure of progress how they are doing with their testing. It also gives them a set of steps of what they can tackle next on their way to testing mastery. Finally, it drives visibility of effort across the organisation.

  • Test planning – the Attribute, Component and Capability (ACC) approach

    It’s been a little while since I wrote my last test plan (start of 2008 maybe?) and I know test case design processes have changed quite a bit (with the adoption of Agile). This seems an interesting way of minimising test design. What I particularly like is the way the it gives you a type of heat map where you may want to focus your testing efforts. Here is a short introduction to the topic.

  • This is a tool that I have been meaning to check out. I heard about it before for writing tests for the web. Now that I do a little more with javascript and stuff in my spare time, maybe it is time to have a closer look again and work some web TDD magic…

  • Layers of automation – small, medium and large (unit, integration and system tests)

    Off the back of this, I also finally understood the importance of different layers of automation. To be fair, this is not really the benefit of this book, but rather of a book I’ve been reading at the same time. Having said that, the layering into small, medium and large and their guideline ratios of 70-20-10 now make a whole lot sense!

Review: “Apprenticeship patterns: Guidance for the aspiring software craftsmen” by Dave Hoover and Adewale Oshineye

(Goodreads link here; free online version by O’Reilly here)

I always find pattern books a weird mixture of

  • lots of useful information which I can’t wait to try out,
  • an overload of information where I’m desperately trying to hang on to what I can

This normally leaves me in a slightly muddled state.

As much as review, I will try to create some order out of chaos or as Daniel Kahneman might put it “satisfy my human desire for consistency”.

This is the first software craftsmanship book I have read. It was first suggested in some discussions of the LSCC meetup group and it then swiftly made it on to my reading list.

Since this was my first formalish introduction to software craftsmanship, I was glad that this book does a great job of explaining (their view of) craftsmanship.

There are – of course – some controversies in the general blogosphere around craftsmanship:

While I don’t know enough about the wider craftsmanship community or indeed the software development community to comment much on this, the view in the book seems to be very inclusive (i.e. against divisions between craftsmen on the one hand and engineers on the other) and value based.

I very much agree with the values and philosophy that seems to underlie the patterns discussed in the books and would summarise them as (some related patterns in [] brackets):

  • Take pride in and enjoy what you do

    [Unleash your enthusiasm; Nurture your passion; Sustainable motivations]

  • Learn for life: There is lots to learn and practice. Everyone has the aptitude to learn and practice

    [Practice, practice, practice; Expand your bandwidth; Read constantly; The Deep End; Confront your ignorance; Breakable Toys]

  • Individuals are responsible for their own learning and for structuring their learning

    [Draw your own map; The Long Road; Record what you learn; Reflect as you work; Create Feedback Loops; Learn how you fail]

  • We are embedded into a community of professionals

    [Be The Worst; Find Mentors; Kindred Spirits; Rubbing Elbows; Share what you learn]

(Of course the craftsmanship community would summarise their views in their manifesto slightly differently themselves.)

These ideals are very inspiring for me and are the kind of values that I would like to align myself with.

The main part of the book – the patterns bit – is based around strategies to help achieving these ideals. As such this is not really a software engineering specific book, but could be used by anyone with similar outlook, aims and struggles.

For me, the most relevant patterns (the ones I’m itching to try out) at the moment are:

  • Breakable toys

    Breakable toys is a way of having toy applications and implementations of technologies you come across and problems you’d like to have a go at solving. It is a way of getting experience without having work / production (quality, criticality etc.) associated with it.

    For the last couple of years, I have used the main application ecosystem that I work on as my stomping ground: Whenever I learnt something, I immediately thought “how can this apply to that application” and “where can I safely implement this”. (Of course not nearly every idea made it into the released final product…). Over time this also guided what I considered to be interesting problems.

    In future, I would like to decouple this a little bit. Build the toy independently of work technologies and considerations first. Then think about whether there is any use for it in terms of work. This approach has a couple of advantages: Those breakable toys are more “my toys” (rather than just stuff I worked on) and they stay mine. It will also expand my bandwidth (play around with node anyone?) and so, ultimately, give me a more rounded view of development technologies.

  • Kindred spirits / Find Mentors

    In my current role, I get to interact with a great bunch of talented, enthusiastic and motivated developers. I have learnt a lot from these guys. Up until now they have been my main source for kindred spirits and mentoring.

    However, their background and what they work on is of course very focussed on enterprise application technology and also the particular business domain (i.e. finance).

    In future, I hope to expand my horizon by finding a wider net of kindred spirits and mentors.

    (That is why the goal is to go to at least one software related talk / meetup / roundtable-y thing a week in diverse communities.)

  • Read Constantly / Reading List

    During my MSc and when I started my job, I rarely stopped reading finance or technology related books. These were mainly on the primary topics I dealt with at the time (stochastic calculus, fixed income, derivatives valuation on the finance side and Effective & Exceptional C++, design patterns, boost, SQL server programming, agile principles etc.).

    As I grew more comfortable with these ideas, my reading slowed a little (I guess the authors would call it “retreat into competence”).
    Now, as my interests expand, my reading list is expanding at quite a fast rate.

    (So there’ll be plenty more reviews like this one I guess.)

  • Expand your bandwidth

    I guess this is the underlying theme of the two previous points. The key point here is for me to take responsibility for my learning and not just to wait until learning opportunities magically appear.

  • Record what you learn
    At the end of the day, the thoughts behind “Record what you learn” are why I have started this blog. Since there is so much to learn out there, I need a record keeping mechanism as well as a scratchpad where I can digest and grapple with new ideas.

Anyway, back to the book review: The patterns are presented in a useful straight to the point format: first giving a brief explanation, then some wider context, some immediate actions, as well as related patterns.

For all of the positivity in the rest of the review, let me be a little more critical for a moment:

  • “New” material

    As the authors themselves admit, the idea behind patterns is not to be “new”, but instead to be tried and tested solutions for common problems. This is definitely true here: I found myself more reminded of things I had done before and wanting to apply those to my current situation.

  • Patterns as a language device
    Patterns of course have a much broader history than the GoF book and there is a whole pattern movement out there. In my mind the benefit of the design patterns has always been to enable communication with others as well as facilitating your own thought process (being able to give something a label as a shorthand). I am not sure whether this communication aspect will really be something I’ll make use of. I can’t really see myself going to my boss or co-workers and talking about “the long road” versus “a different road”. This doesn’t mean the underlying ideas are not useful, but I am not sure (yet) about using these shorthand labels.
  • Stretching the craftsmanship analogy

    I like the craftsmanship analogy for software (or general life). In some senses, they remind me of the four stages of competence. After a little while though the metaphor wears a little thin: rather than just looking at the main point of the metaphor the authors sometimes rely on incidental aspects of it.

However, even given those (slight) negatives. This is a great book to read, if you are looking to

  • re-awaken your enthusiasm for programming
  • critically re-examine your current practice
  • you are short of items on your reading list

    (reading through this my “outstanding” reading list increased substantially)

Review: “The Node Beginner Book” by Manuel Kiessling

I have recently started dabbling with Node.js. A local meetup I stumbled across called stack kitchen is to blame for this dabbling:

Before the talk, I felt a little self-conscious about my node & javascript skills and went looking for somewhere to get the basic low down on node.

Being a lazy Google-user, I did not make it far down the list of results (or even try a very specific search) and used this tutorial.

About halfway through, I realised that the site was actually plugging a book – so I bought the book and worked through the rest of the book.

There are of course lots of other tutorials to choose from out there – probably because node is the flavour of the month (or given how hip I am the flavour of last month…).

Other tutorials and node resources are for example:

  • This focusses on node as a script host, not so much on the typical use case as a web server.

    I liked that it gets you started quite quickly and also mentions some important main features (interactive shell, packager manager, modules, callbacks). A good quick start guide if you want to start hacking things together.

  • This is more of a blog than a tutorial. It covers lots of different stuff. Probably not a place to come back to later, but not for finding your feet.

  • Felix (much like Tim who is man behind “How to Node”) is one of the early contributors to node. This website is really several guides in one: a tutorial to get you started, a guide on the community, a style guide and a guide on how to convince your boss (aka when to use node).

(This list was compiled on the couch on a lazy Saturday morning. So… let me know about other cool Node resources!)

How do you choose between those and this book?

If you’re like me, you’ll just take a chance on the first one you stumble across, but “The Node Beginner” book might be for if you…

  • …are interested in using node on the web server
    Almost all of the book (apart from the initial hello world example) is organised around a couple of (toy-like) web server use cases. There is e.g. no mention of using the node shell or script / parsing like examples.
  • …have some experience in programming, but not really in javascript

    This book assumes almost no familiarity with javascript. I reckon you could probably get away with knowledge of any OO language. Some server side exposure might help. (I have played around with javascript mainly for mobile and client side toys in conjunction with frameworks like knockout and even knowing only these toy use cases I found some of his explanations a little long winded.)

  • …are interested in different components of a web server and how they hang together

    The separation in to different modules such as the server, the router, the request handlers and view generation was one of the parts I enjoyed the most. While this is well covered, familiar ground (Skonnard e.g. covers similar handling and routing for WCF RESTful web services here), there was very much a beautiful simplicity to the toy implementation here.

  • …like a blog post writing style

    Writer’s style obviously comes down to personal preference, but I really like the style of the book. While sometimes a little long-winded, things are explained in a clear and logical way. Steps are laid like the thought process of somebody developing their first node application. For me this kind of approach fits very well.

Beyond this (and in the interest of adding yet more bullet points), there were some particularly interesting insights here for me:

  • …how strikingly easy it was to set up a simple server

    You literally need nothing more than node installed and the six line long javascript sample on the node.js website. Wowsers.

  • …how you then still need to hack your server components together
    There was a fair amount of reinventing the wheel in the book. However, to appreciate how much you need to really reinvent the wheel and how much was just a teaching device, I really need to dig a little deeper into existing node packages. Initial impressions are that there are loads and loads of packages.
  • … execution model

    This is one of the things I really still need to get my head around. I get the basic description in the tutorial of the importance of non-blocking operation and a single threaded event loop ….but… I really need to understand this a little better, e.g. how things are executed asynchronously. This seems like quite a good place to start – contrasting node with IIS&WCF.

  • …the ease of use of package managers

    I know this is the order of the day for almost any programming language out there now, but for C++ devs, this is still a big leap. I know Microsoft has expanded NuGet for native use, but because of C++’s reach across different compilers I’m a little sceptical of the widespread adoption of this.

For me, the next stop on the road of learning of node is “Hands on: Nodes.JS” by Pedro Teixeira.
This book comes bundled with the “Node Beginner Book”. Having read some of the first chapter (and glanced through the table of contents), this feels much more like a “grown-up” book. Lots of references to different patterns etc.

The plan is to also start building some breakable toys in Node. (Can you tell I’ve been reading a book about Apprenticeship patterns?). Those toys might make a good first use for my blog github repo.

ReadingList.emplace_back(“Elements of Programming”)

I’m currently writing up my first “proper post”. Something which actually has some content. It’s going to be a review of some of the Going Native 2013 talks you can see over at Channel 9.

While reading up on the various talks and materials surrounding the talks, I came across a comment by Sean Parent recommending Alexander Stepanov’s & Paul McJones’s “Elements of Programming“.

Having watched the Stanford lecture in which they describe the book, I am quite intrigued by the approach and the book has definitely made it on to my reading list.

The idea here seems to be to foster greater and deeper understanding of programming through linking programming with mathematical theory. In particular, the assertion seems to be that programming is a continuation of the practical application of algebra. (…although not having read the book yet, I could of course be totally wrong.)

On the Amazon reviews (as well as the audience Q&A in the video), there appear to be some discussions whether this truly covers new ground in computer science theory. Given that this is an area where I don’t have much prior exposure, there is only one way of finding that out. Read it (and get out pen & paper for some working through it)!

PS: I’ll link to my Amazon reading lists as soon as I have a moment tomorrow.