std.Thread.Condition: error: no member named 'unlock' in struct 'std.Thread.Mutex' #8051
Labels
bug
Observed behavior contradicts documented or intended behavior
standard library
This issue involves writing Zig code for the standard library.
Milestone
Comments
SpexGuy
added
bug
cescude
added a commit
to cescude/zig
that referenced
this issue
Apr 17, 2021
This also changes the `wait(...)` signature to take a `Mutex.Impl.Held`
object instead of a plain `Mutex`, which IIUC is clearer to the intent
of the function (ie., you should be passing in a locked mutex, not just
any mutex).
For example:
var mutex = Mutex{};
var cond = Condition{};
var held = mutex.acquire();
defer held.release();
while (bad_state == true) {
// cond.wait(&mutex); // <-- Original
cond.wait(&held); // <-- Updated
}
Not really a breaking change for code using `AtomicCondition` (since it
didn't compile before), but this does affect the other implementations
and would presumably break anything using that code as well.
kprotty
pushed a commit
to kprotty/zig
that referenced
this issue
Jun 11, 2021
This also changes the `wait(...)` signature to take a `Mutex.Impl.Held`
object instead of a plain `Mutex`, which IIUC is clearer to the intent
of the function (ie., you should be passing in a locked mutex, not just
any mutex).
For example:
var mutex = Mutex{};
var cond = Condition{};
var held = mutex.acquire();
defer held.release();
while (bad_state == true) {
// cond.wait(&mutex); // <-- Original
cond.wait(&held); // <-- Updated
}
Not really a breaking change for code using `AtomicCondition` (since it
didn't compile before), but this does affect the other implementations
and would presumably break anything using that code as well.
nuald
pushed a commit
to nuald/zig
that referenced
this issue
Nov 13, 2021
This is a breaking change. Before, usage looked like this: ```zig const held = mutex.acquire(); defer held.release(); ``` Now it looks like this: ```zig mutex.lock(); defer mutex.unlock(); ``` The `Held` type was an idea to make mutexes slightly safer by making it more difficult to forget to release an aquired lock. However, this ultimately caused more problems than it solved, when any data structures needed to store a held mutex. Simplify everything by reducing the API down to the primitives: lock() and unlock(). Closes ziglang#8051 Closes ziglang#8246 Closes ziglang#10105
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Compiling
with
zig build-exe bug_m.zigresults inThis is in
AtomicCondition,pub fn wait(cond: *AtomicCondition, mutex: *Mutex) void.Note:
PthreadConditionis not affected. (zig build-exe -lpthread bug_m.zig)System information:
The text was updated successfully, but these errors were encountered: