Last week, we delved into the scenario of two OSC messages sent at the exact same time. Exploring how they interact on a physical level, with a focus on voltage changes on a wire.

Basically, how the physical layer ensures that messages “don’t cancel each other out”.

And, what about the software side?!

What if two OSC messages come through “TOO close to each other”?

What if it’s not just two, but a hundred messages? Will the software get knocked over?

“Hold up OSC, I’ll come back to you once I’m done with this client”

Well, no and yes. It all depends on buffering, concurrency and synchronization.

All software defined network socket provides a buffer that stores messages if the software isn’t yet done with a previous message.

So, in the event of two ore more messages arriving very close together, we’re save.

And as those buffers can be increased quit a bit, even several more messages than just a few dozen can be safely “stored away” for later processing.

“Hey, could you open up a second checkout?!”

“Concurrency” in computing can be compared to checkouts at the convenience store.

Either scanning the next clients items while the first clients credit card payment is still processing (aka tasks) or, opening a second or third checkout lane all together (aka threading);

Both allow more customers to be served at the same time, reducing wait times and buffering (queuing up).

And this is where it gets really messy! “synchronization”

Because, with multiple threads comes a huge responsibility.

“I’m sorry, somebody already has the key to the bathroom. You’ve got to wait”

“Too late 🫣”

And here we are: The ultimate end boss for two messages getting handled at the exact same time!

And, the key to the bathroom (we developers call this a Lock or Mutex) is just one mechanism that can either helps us or break us.

To stay with the messy bathroom example, there’s even a method for an urgent situation like this. Although it’s quite rude in real life 😂

Banging on the bathroom door, cursing at the occupant to “hurry the fck up”!

This so called “preemptive scheduling” is common practice in high priority control systems. If the new message is reeeeeally important, you throw more processing power at the blocking process to help finish up faster.

But, you have to let this process finish up first. Because some processes are “atomic operations” (Greek atomos means uncuttable). They have to finish all the way through… I leave this to your imagination…

And here we are.

A weird question led us on a field trip from rude controllers and polite network cards, over crowded convenience stores to messy gas station bathrooms.

Who would have thought that.

So long

Basti