Race Conditions

written by Dave Krahl, QMT Group

In computer science and engineering a race condition is "an undesirable situation that occurs when a device or system attempts to perform two or more operations at the same time, but because of the nature of the device or system, the operations must be done in the proper sequence to be done correctly". In discrete event simulation programs such as ExtendSim, a race condition is when multiple events happen at the same simulated time and the order of these events has an impact on the operation of the model. Because discrete event simulators process events at discrete times, race conditions are fairly common. There is no standard solution to this, and it is handled differently by the various simulation software programs. When an event occurs in a discrete event simulation model any number of actions can be triggered. The order of these actions can have a significant effect on the behavior of the model. A classic example is if a resource is released and the item (or entity) releasing that resource requests the same resource again and other items are waiting for that resource. Is the releasing item in contention for the resource?

ExtendSim has a number of features that provide additional control over the sequence and scheduling of events as well as the transmission of messages. These include:

• Scheduling a 0 time event in an equation before it is evaluated. This provides the ability to delay the calculation of the equation and any subsequent messages sent by the equation returning control to the block that initiated the calculation. This can be implemented in custom blocks as well.
• Detailed control of messages in the equation and custom blocks. Whether or not a connector responds to a message is a user-defined option.
• In custom blocks, there are message handlers for every type of interaction. These can be used to control how other messages are sent out.

While there are numerous tools for solving race condition problems, the biggest challenge is detecting them in the first place. This often requires detailed inspection of the results of an event in the simulation. Some tools available for this in ExtendSim are:

• Tracing of simulation execution
• Enabling debugging code and in particular examining the "stack" of function calls and message handlers
• Animation of item movement
• Record Message block in the ExtendSim Utilities library shows sequences of messages
• History block that shows item movement and properties.

Race conditions are an artifact of discrete event simulation as a technology. This issue is something that every experienced simulation modeler has encountered in their modeling experience. Identifying the race condition can be challenging. However, tools exist in simulation programs to address any race condition problems and control the execution of the model.

Making a Backup Of your Model

It is an excellent idea to make a backup of your model from time to time.  This could be useful if you want to go back and open a previous model version.  In order to do that, you should periodically make a complete backup of your model and any additional files it might need.  You might not be able to run an old model if you don’t.  The complete archived model should include the same elements you would need to include if you sent the model to someone else to run.  Every model might not have all of these elements, but if they do, store them with that current version of the model.  The list is as follows:

• Model
• Custom libraries *
• Custom Include files **
• Pictures used for animation
• External Data Files you are Importing from or Exporting to

* You don't need to backup the standard libraries which are installed with ExtendSim.  You only need to back up your custom libraries that are used in the model if you have any.  You might not have any but you will know it if you do.

** You don't need to backup the standard include files which are installed with ExtendSim.  You only need to back up your custom include files if you use any in custom block or the standard Equation blocks.

Consider one simple example of why you want to archive files along with the model itself.  Suppose we have an Excel workbook that is used to import data from the beginning of the run.  Let's say we have one tab for each of the input tables.  When we made a backup of the model, we did not back up anything other than the model.  Suppose we start working on the input data and made some changes to the model and the Excel workbook.  If we wanted to open the previous model and run it, we would have the archived model but we didn’t backup the spreadsheet so we would only have the updated spreadsheet.  The old model wouldn't understand what to do with this updated Excel file.  There would be a mismatch.  We would be able to open the model up in this case, but we couldn't run the model. 

The same concept applies to all the other files in the list above.  If we don't include them in the model backup, then when we go and open the backup model it may or may not work properly if there have been changes to the library files, include files, pictures, or data files.  These files can change over time as you enhance your model so it would be a great idea to keep a copy of these files with the model backup.

I use WinZip to make a complete backup of all the required files, but other tools could be used as well.  If you are working in a group of model developers, and everyone is working on the model, then something more advanced should be used which allows each user to "check in" changes on each individual file.  Source control tools can be used here.  The source control tools work well for keeping track of changes if the users document changes appropriately.

If you need to send your model to someone else to run, this same backup can be used.  Just don’t forget to include all necessary files. Your model might not contain all the files in this list, but if it does, then you will need to include it in the backup. 

Best Practices for Modeling

Below are some best practices for modeling.

Document first

Don’t wait until the end of model development to start the documentation process.  Documentation should help the developer communicate with the subject matter experts regarding what needs to be included in the model and the assumptions the model will make.  Do the documentation first and validate it with the SME.  Let the documentation help guide development so the constructs will be developed only ONCE!  You will most likely pay a high penalty by having to rework the complex constructs if you don’t address documentation first.  Documentation before construction will help reduce wasteful and time-consuming rework.  Build the model right the FIRST time!  This will help the model builder.

Test as you go

Don’t wait to the end of model development to start testing.  Test as you build.  If you wait until the end to verify the model works correctly, it will take much longer to find bugs because you have to search through the entire model. Build the model in small chunks and test thoroughly as you go.  If you test as you go, the new bugs will be in the constructs you have just built.  You will be focused on a smaller construct to look for the bug while that logic is fresh on your mind.  This is such a crucial aspect of the modeling process that it deserves mentioning more than once!

Build a clean model as you go

Don’t wait until the end of model development to start cleaning up the model.  Messy models take much longer to debug! You might build a construct today and not touch it again for a few weeks or months.  As a result, you will forget the details in the complex constructs.  A messy model is confusing once you return to it, and it requires you to spend extra time trying to remember what each construct is doing. A clean and well-built model is much easier to read and understand, which results in spending less time finding errors.  This will help the model builder.

Build the interface first

The interface should allow the model user quick and easy access to important input and output variables and various model functions.  If the user interface is not created until the end of development, then you have missed out on a fabulous opportunity to use those quick access features.  Not using a model interface will slow model development because you are taking the long way to do things.  Creating it at the beginning helps guide the developer with a clearer picture of what should or should not be in the user interface because the variables and tools have been used throughout the entire process. Beginning with the interface also leads the developer to think about the end product first and clarifies the process of building toward that endpoint.  This will help the model builder.

Use Animation for Debugging

Don't wait until the end to add animation.  Animation can and should be used as a way to help detect bugs in your model in addition to making it look pretty.  So consider adding nice animation from the start.  

Ask for help

Ask for help when needed.   If you are new to modeling, your first task should be finding someone who can help when you need it.  Your go-to person may be a more experienced coworker or an instructor in a training class.  While there’s real and irreplaceable value in learning through your own trial and error, part of the learning process is in knowing when it’s time to move on and ask for help.  Don’t waste excessive time trying to figure out how to do something. 

Use the buddy system

Don’t go off on tangents or get sidetracked.  Modeling can sometimes be more effective if you work with a buddy.  When you are modeling on your own it is easy to go down a path that is nonproductive and diverts you from the primary goal.  When you model with a buddy, you are more likely to get back on the right path quickly because you can encourage each other to stay focused. Modeling with someone else tends to work like bumpers in a bowling alley.