Comment by Yoric | Hacker News Reader

Comment by Yoric | Hacker News Reader

Parent Full thread

Here's a short toy example in pseudo-syntax.

Task 1:

global.a = 1

await async {} // Await a block that does nothing, essentially yielding back to the reactor.

print(global.a) // If you're unlucky, global.a has changed.

Task 2:

global.a = 2

await async {} // Await a block that does nothing, essentially yielding back to the reactor.

print(global.a)

Now enqueue both tasks.

Depending on scheduling, you could end up printing (1, 1), (1, 2), (2, 1) or (2, 2). This can become much worse if you're awaiting in the middle of filling a data structure.

Feel free to replace `await async {}` with querying your database or a remote API and `global.a` with any variable or data structure that can be shared between the tasks.

This example is, of course, a toy example, but I've had to debug sophisticated code that broke non-deterministically because of such behaviors. The source code of the front-end of Firefox (written in JavaScript) is full of hand-rolled kinda-Mutex implementations to avoid these race conditions.

Thank you for the clarification. You are right, these types of race conditions are possible with Async Ruby.

I find these races relatively easy to spot: yes, global state CAN change when you yield back to the reactor.

IMO thread race conditions are much, much worse. Global state can change AT ANY POINT, because thread scheduler preemptively switches threads. Here's an example:

    global.a = 0

    thread {
      global.a = 1
      print(global.a) // a is 1 or 2
    }

    thread {
      global.a = 2
      print(global.a) // a is 1 or 2
    }

    print(global.a) // a is 0, 1 or 2

> I find these races relatively easy to spot: yes, global state CAN change when you yield back to the reactor.

It's good that you can find them easily. In my experience, these changes can creep into your code stealthily and only hit you from behind, months later, when the winds shift.

Some of my traumas include:

- global state that ends up captured by a closure while you didn't realize it was (perhaps because the code you wrote and the code the other dev wrote accidentally shared state);

- mutating hashtables/dictionaries while walking them, without anything in your code looking suspicious;

- and of course accidentally mixing concurrency between two reactors, but luckily, that's not something that happens every day.

> IMO thread race conditions are much, much worse.

IMO, thread race conditions are a case of "it's bad but you knew what you'd get when you signed up for it", while async race conditions are a case of "don't worry, everything is going to be fine (terms and conditions apply, please contact your lawyer if you need clarifications)".

This isn't really an issue with threads though, the exact same issue is present in green thread/fiber implementations; it just so happens that in Async Ruby the GIL saves you from this specific problem due to making variable accesses atomic (as I understand it anyway, I'm not super familiar with the Ruby VM).

In general, green threads/fibers are vulnerable to the exact same shared memory issues as threads, the only benefit to them is that they are, for a certain class of problems, a more efficient concurrency primitive than threads by avoiding context switches out of userspace, and in many cases provide you the ability to plug in your own scheduler if you so desire allowing you to optimize scheduling for your own workload.

Thank you for sharing your perspective in a non-conflicting way Yoric.

It seems you have more experience than me with async-related work. I'll keep an eye on this kind of scenario you brought up.

Reply on news.ycombinator.com