thread local variables

[andrewrk]

var x: i32 = 1; // global variable
threadlocal var y: i32 = 2; // thread local variable

here's 1 use case (taken from std/debug/index.zig):

var panicking: u8 = 0; // TODO make this a bool

pub fn panicExtra(trace: ?&const builtin.StackTrace, first_trace_addr: ?usize,
    comptime format: []const u8, args: ...) noreturn
{
    @setCold(true);

    if (@atomicRmw(u8, &panicking, builtin.AtomicRmwOp.Xchg, 1, builtin.AtomicOrder.SeqCst) == 1) {
        // Panicked during a panic.

        // TODO detect if a different thread caused the panic, because in that case
        // we would want to return here instead of calling abort, so that the thread
        // which first called panic can finish printing a stack trace.
        os.abort();
    }
    const stderr = getStderrStream() catch os.abort();
    stderr.print(format ++ "\n", args) catch os.abort();
    if (trace) |t| {
        dumpStackTrace(t);
    }
    dumpCurrentStackTrace(first_trace_addr);

    os.abort();
}

[PavelVozenilek]

1. The compiler should emit a warning/error if thread local variable is used by single thread only.
2. Taking pointer of such variable and passing it to other threads may be forbidden by the compiler.
3. When the value is initialized at comptime: is it calculated once, stored somewhere and then initial value set for every thread? What if comptime evaluation returns different value each time, say some unique number?

[phase]

Instead of making this a language-level feature, could this be implemented in the standard library?

[bnoordhuis]

Technically yes but you'd miss out on out-of-the-box tool support. gdb and lldb know about .tbss and .tdata segments; any zig-specific scheme they would need to be taught first.

1. The compiler should emit a warning/error if thread local variable is used by single thread only.
2. Taking pointer of such variable and passing it to other threads may be forbidden by the compiler.

I don't know if that is a reasonable expectation, that kind of data flow analysis is a Hard Problem. I'm not even sure it's possible in general without imposing additional restrictions à la linear types.

[bheads]

For thread safety you may want to consider thread local by default and require the user to declare memory as global. Thread local and and a thread safe way to move memory between threads would be a huge win.

[andrewrk]

For thread safety you may want to consider thread local by default and require the user to declare memory as global.

I understand this is what D does, but I'm not convinced this is the best thing to do. Thread local data has a very specific use case but it is not a general solution to data races within a thread. For example, thread local buffers cannot be used in a function which is directly or indirectly recursive. It also comes at a cost. Less thread local data makes threads less expensive.

[bheads]

@andrewrk Just spent an hour dealing with a thread local bug in D, I think you are right...

[nordlow]

I'm curious...what alternatives to thread-local-by-default are you thinking of, @andrewrk?

Rust-style ownership and borrowing?

Pony-style builtin actor-model with thread-local deterministic GC?

[isaachier]

@nordlow who said the alternative is more complex than the simple approach above: threadlocal var y : i32 = 2;?

[nordlow]

Doesn't that put Zing in the inter-thread-data-races-by-default language group?

Which is what languages such as Rust and D has "designed away" and I thought no new system language ever will have again?

[isaachier]

As I've said in another issue, that is exactly what Zig's specialty is: allowing precise control over dangerous scenarios as long as errors are returned explicitly and not thrown up the stack. That way the user is in control of the behavior, whether or not races are involved. I think Zig competes with Rust because it is much more flexible and does not burden the user with proofs of correctness upfront. That can always be added later using external tooling/annotations (see Frama-C for an example of this). Personally, I don't see the use of globals being thread-local by default even when threads aren't being used.

[nordlow]

Are you saying that Zig will statically detect data-races and notify them to the developer as compilation errors?

[isaachier]

I doubt it. Does C do that? More likely a runtime tool will exist to check for races (similar to Clang's ThreadSanitizer). If you are looking for a language that makes it impossible to shoot yourself in the foot, I think Zig is not the answer. If you want a language that lets you shoot yourself in the foot, but provides a myriad of ways to avoid it and detect it, then Zig is the answer.

[andrewrk]

I'm curious...what alternatives to thread-local-by-default are you thinking of, @andrewrk?

It sounds like you see thread-local-by-default as solving some problem, and I challenge that here: #924 (comment)

For concurrency (See #174), I'm experimenting with async/await (an event loop with coroutines multiplexed upon kernel threads) and atomics in the self-hosted compiler. If I can show that you can use higher level abstractions in this style relatively easily, then I think the problem is solved.