Hacker News Reader

Comment by tomp | Hacker News Reader

It's not that Arrays are not thread safe; it's just that the code was written in a non-thread-safe way.

Writing

  x[i] -= 1

actually means

  x[i] = x[i] - 1

So, there's a read, a subtraction, and a write, and they all happen sequentially. Since they are not in a transaction or protected by a mutex, nothing guarantees that other thread don't mutate `x[i]` in the mean time.

This has nothing to do with Ruby, and nothing to do with multicore, either. Even on a single CPU core, threads might interleave and cause unexpected behavior.

View on HN

I came to this comment thread specifically to point this out, but you beat me to it.

It has nothing to do thread safety, and everything to do with atomicity. This is not a single atomic operation, but rather three atomic (and thread-safe) operations which are bound together with the assumption that the entire thing is atomic when it is not.

    # you might as well imagine this happening
    original = x[i]
    new_val = original - 1
    x[i] = new_val

Which is why you need to use a mutex to make the entire operation atomic, at a small performance cost.

The Objective-C compiler actually adds a nice bit of syntax for this, you can simply wrap your code in @synchronized:

    @synchronized(self) {
         int original = x[i];
         int new_val = original - 1;
         x[i] = new_val;
    }

If I understand correctly, this corresponds to `lock` in C#:

    lock (_gate) {
        x[i] --;
    }

At least in C# it is considered preferable to lock on a private field, as opposed to locking on `this`, so nobody else also locks on your instance, potentially causing a deadlock.

I suppose this applies to `@synchronized` in Objective C as well.

I like that .NET Framework also provides some useful atomic methods, including this one:

    Interlocked.Decrement (ref x[i]);

They come in handy.

That's not quite true. The language spec can mandate that the -= be atomic (the X86 equivalent is mandating a LOCK).

Technically it'd have to mandate that []-= be atomic, there's a load from and a store to a k:v collection, not just from and to memory.

> there's a load from and a store to a k:v collection

That is itself a separate specification question: does simple array access trigger full load/store semantics or is it simply returning a reference?

Note that it's not a "simple array" here it's an associative one, a map. And of course it's not just access, it's the retrieval of a reference to an immutable cell, you can't just alter it in place unless you are certain no other reference to the cell exists in the system.

> Note that it's not a "simple array" here it's an associative one, a map. And of course it's not just access, it's the retrieval of a reference to an immutable cell, you can't just alter it in place unless you are certain no other reference to the cell exists in the system.

This still comes down the question of whether your language preferes references or values: a design decision in-scope for the original question. A language designer might quite reasonably choose to specify that `foo[i] -= 1` means “Get a reference to the object at position i in container foo and tell it to decrement”, in which case the container access is not a concurrency issue except for write / replacing the initial object. This approach can also be implemented atomically in many architectures because it's a simple arithmetic operation rather than retrieving and storing immutable objects.

It would also potentially be easier to scale if threads don't typically update the same elements because you could perform locking at the cell level rather than the entire container.

Totally agreed. Why do I have to lock it myself (even on a high level language like Ruby)? I'm not programming for C!

You only have to do it yourself once you decide to use threads.

And there is not really a way around that. If the language mandated that all primitive operations (for whatever reasonable operation of 'primitive') were atomic, most multi-threaded programs would slow down to a crawl.

Even ignoring that, having atomic primitives is not sufficient to prevent race conditions. Things like "if balance > withdrawal {balance -= withdrawal; ...} need larger ranges of locking, and no compiler is going to tell you how large they have to be.

Reply on news.ycombinator.com