It's Sean!

UK freelance journalist, author
and writer Sean McManus

Printed from © Sean McManus.
You are here: Home > Blog Home > Sean McManus's Writing blog: Avoiding the race condition bug in Scratch

Sean's Tech and Writing Blog

Avoiding the race condition bug in Scratch

03 July 2014

When I discovered Scratch, I was fascinated to see that the language enables you to put scripts on different sprites, or multiple scripts on the same sprite, that appear to execute at the same time. This is a bit like threading, an advanced programming technique that enables you (in very basic terms) to have different bits of a program executing in parallel (at the same time).

There is a special class of bug that emerges when you're dealing with parallel code, which is the race condition. This happens when two different bits of the program "race" to do something at the same time, and the programmer doesn't have control over which "wins".

For example, if I put all these scripts on the same sprite, what is the final value of the score variable?

four scripts that start on the green flag and all change the variable score to something different

It doesn't matter what your guess is, because there's no sure way of knowing how it will behave next time. It might change depending on what else is going on in the program, or a minor update to Scratch might change the synchronisation too. Logically, it's not something you can control. If you ask the program to do four things at the same time that don't make sense together, you risk getting unexpected results.

From my own quick and dirty experiments, it looks like the one that runs last (and ultimately sets the score) is the one you edit or move last. So if you, in the editor, drag the set score to 0 block and then click the green flag, the final value of score is 0. To get the value 8, drag the blocks in this order: set score to 0, set score to 5, change score by 2, change score by 1, and then click the green flag. I put all these scripts on the same sprite. When you have more than one sprite with conflicting scripts on it like this, sprites that were added to the program first have higher priority over the final result. So the cat seems to trump other sprites, for example. I ran my test in Scratch 2.0, but the results are different in Scratch 1.4, and might even be different for you running Scratch 2.0. And they might be different tomorrow for either of us. There's no reason why they have to stay the same.

That's a bit of a diversion because this information isn't really useful to you: for the program to make sense to others (an important part of programming), and to always run reliably (even if someone else moves a script), you need to avoid race conditions like this, not work around them.

It might seem like this is a bit of an artificial example (okay, it is), but similar problems can often occur when lots of scripts start when the green flag is clicked, or the background changes, or when there is a particular broadcast. There have been a couple of times I've experienced problems similar to this, including when writing Hangman for my book Scratch Programming in Easy Steps and the Shaun the Sheep Football game more recently.

There are a few strategies you can use to avoid race conditions:

  1. Avoid having more 'green flag' or other hat scripts (with rounded tops) than you need. If you can combine them without causing any problems, it's best to do that. That enables you to determine the order the blocks run in.
  2. If you have a bug that might be caused by a race condition, try adding wait blocks to delay some of your scripts so they execute in an order you can influence. This is a real fudge so I wouldn't recommend it for final programs, but it can be valuable for finding bugs when you're testing your program.
  3. Use Scratch broadcasts to synchronise between sprites where necessary. For example, you could have a green flag script that sets up your variables and gets everything else ready, and then sends a broadcast to start scripts on other sprites. That avoids a clash where the other sprites might be trying to use variables you haven't set up yet (for example).
  4. Use the broadcast and wait block where it makes sense. That stops your script steaming ahead before getting the results it needs from other scripts that it's triggering.

Have you experienced bugs like this? How did you overcome them? Let me know in the comments below.

For more on Scratch, take a look at my books Cool Scratch Projects in Easy Steps and Scratch Programming in Easy Steps.

Bookmark and Share
Permanent link for this post.


Excellent post, Sean.

I've been a professional programmer for 15 years (and an amateur/student one for another 15) -- and I still get stung by race conditions from time to time.

They're a real pain because often things work perfectly well when you step through with a debugger, and when you run tests on lightly loaded machines -- then screw up intermittently in the real world.

As you learn Scratch is a great time to understand race conditions, and learn to not create them in the first place.
Thank you, John. I used to write a blog about parallel programming a few years ago and at that time university courses were only covering parallel programming as an option. As a result, many graduates weren't being taught about this problem, which comes up a lot in the real world. I don't know how much that's changed, but it's fantastic that Scratch enables many people to learn about this in their very first programming language.
I did the parallel programming module at university, and it didn't really cover this kind of thing - it was more about distributing a computing task across multiple processors.

In languages like C and Java, we have ways to waiting for threads, telling waiting threads to continue, ways to tell routines to only let one thread "in" at a time. With these we can make the threads perform a little dance around each other so they don't tread on each others' toes -- but code it wrong and they will trip up.

In Scratch we have none of those features (rightly - because it would be too complicated) and that's good because it encourages you to come up with cleaner ways to synchronise the dance. Yet when you move on to a "grown up" language, you're going to be excited about the new tools you get to choreograph the dance.
And the great thing is that if you're aware of the problems caused by race conditions, you're more likely to look for language features that solve these problems when you move to C and Java later.
Post a Comment

Blog Home | Website Home

Dip into the blog archive

June 2005 | July 2005 | August 2005 | September 2005 | October 2005 | November 2005 | December 2005 | January 2006 | February 2006 | March 2006 | April 2006 | May 2006 | June 2006 | July 2006 | August 2006 | September 2006 | October 2006 | November 2006 | December 2006 | January 2007 | February 2007 | March 2007 | April 2007 | May 2007 | June 2007 | July 2007 | August 2007 | September 2007 | October 2007 | November 2007 | December 2007 | January 2008 | February 2008 | March 2008 | April 2008 | May 2008 | June 2008 | July 2008 | August 2008 | September 2008 | October 2008 | November 2008 | December 2008 | January 2009 | February 2009 | March 2009 | April 2009 | May 2009 | June 2009 | July 2009 | August 2009 | September 2009 | October 2009 | November 2009 | December 2009 | January 2010 | February 2010 | March 2010 | April 2010 | May 2010 | June 2010 | August 2010 | September 2010 | October 2010 | November 2010 | December 2010 | March 2011 | April 2011 | May 2011 | June 2011 | July 2011 | August 2011 | September 2011 | October 2011 | November 2011 | December 2011 | January 2012 | February 2012 | March 2012 | June 2012 | July 2012 | August 2012 | September 2012 | October 2012 | December 2012 | January 2013 | February 2013 | March 2013 | April 2013 | June 2013 | July 2013 | August 2013 | September 2013 | October 2013 | November 2013 | December 2013 | January 2014 | February 2014 | March 2014 | April 2014 | May 2014 | June 2014 | July 2014 | August 2014 | September 2014 | October 2014 | November 2014 | December 2014 | January 2015 | February 2015 | March 2015 | April 2015 | May 2015 | June 2015 | September 2015 | October 2015 | December 2015 | January 2016 | February 2016 | March 2016 | May 2016 | July 2016 | August 2016 | September 2016 | October 2016 | November 2016 | December 2016 | January 2017 | Top of this page | RSS

Books by Sean McManus

Scratch Programming in Easy 


Scratch Programming in Easy Steps

Raspberry Pi For Dummies

Raspberry Pi For Dummies

Learn to program with the Scratch programming language, widely used in schools and colleges.

Set up your Pi, master Linux, learn Scratch and Python, and create your own electronics projects.

Super Skills: How to 


Super Skills: How to Code

Web Design in Easy Steps

Web Design in Easy Steps

Learn how to code with this great new book, which guides you through 10 easy lessons to build up your coding skills.

Learn the layout, design and navigation techniques that make a great website. Then build your own using HTML, CSS, and JavaScript.

More books

©Sean McManus.