Home > Sean's Technology 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:

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.
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.
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).
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.

Permanent link for this post | Blog Home | Website Home | Email feedback

Dip into the blog archive

Credits

Visit www.sean.co.uk for free chapters from Sean's coding books (including Mission Python, Scratch Programming in Easy Steps and Coder Academy) and more!

Discover my latest books

100 Top Tips: Microsoft Excel

Power up your Microsoft Excel skills with this powerful pocket-sized book of tips that will save you time and help you learn more from your spreadsheets.

Scratch Programming IES

This book, now fully updated for Scratch 3, will take you from the basics of the Scratch language into the depths of its more advanced features. A great way to start programming.

Mission Python

Code a space adventure game in this Python programming book published by No Starch Press.

Cool Scratch Projects in Easy Steps

Discover how to make 3D games, create mazes, build a drum machine, make a game with cartoon animals and more!

Raspberry Pi For Dummies

Set up your Raspberry Pi, then learn how to use the Linux command line, Scratch, Python, Sonic Pi, Minecraft and electronics projects with it.

Earworm

In this entertaining techno-thriller, Sean McManus takes a slice through the music industry: from the boardroom to the stage; from the studio to the record fair.