core/mutex: clean up #18619

maribu · 2022-09-21T11:20:33Z

Contribution description

This restores a pre-existing design decision to implement both blocking and non-blocking mutex locking with the same code. Those implementations have been split prior to the introduction of the core_mutex_priority_inheritance module when mutex_trylock() indeed was trivial. This decision didn't age well, so undo it.

Testing procedure

Let's have the CI run some tests.

Issues/PRs references

None

benpicco · 2022-09-21T12:35:16Z

Static tests has some comments, otherwise this looks good.
Are you sure you can drop mutex_trylock_ffi()?

chrysn · 2022-09-21T12:50:53Z

I don't know of any code that used mutex_trylock_ffi directly -- but only reading this patch I saw that it was not supposed to be used directly (but through mutex_trylock which would already have picked the right implementation). If others made the same mistake, a note would be due that mutex_trylock_ffi is not needed any more, or a deprecated alias.

(This is sidestepping the question of whether trylock should or should not stay inlined down to the busy parts; about that, I don't care).

maribu · 2022-09-21T12:54:47Z

core/include/mutex.h

- * @internal
- * @note    This function is intended for use by languages incompatible
- *          with C (such as C++). Code in C should use @ref mutex_trylock
- *          instead


Are you sure you can drop mutex_trylock_ffi()?

The doc says it is internal :)

core/mutex.c

maribu · 2022-09-21T13:18:10Z

I also applied @fabian18 's comment in #18620 (comment)

benpicco · 2022-09-21T19:59:15Z

core/include/mutex.h


 #include "kernel_defines.h"
 #include "list.h"
 #include "thread.h"

-#ifndef __cplusplus
-#include "irq.h"


CI found some users that relied on this implicit include. Better add the include to the .c file that makes use of it.

Looks like there are still some missing.

bme680_hal.c also needs an update

maribu · 2022-09-22T18:26:20Z

This looks like the rust bindings do care that mutex_lock() now is static inline :-/

Update this is the log of a random failed build:

-- running on worker breeze thread 1, build number 4090.
make: Entering directory '/tmp/dwq.0.828799345211067/1d1268c526f23e2d84dbe3f5848970a9/examples/rust-hello-world'
make: Leaving directory '/tmp/dwq.0.828799345211067/1d1268c526f23e2d84dbe3f5848970a9/examples/rust-hello-world'
make: Entering directory '/tmp/dwq.0.828799345211067/1d1268c526f23e2d84dbe3f5848970a9/examples/rust-hello-world'
Building application "hello-world" for "cc2538dk" with MCU "cc2538".

   Compiling proc-macro2 v1.0.39
   Compiling unicode-ident v1.0.0
   Compiling autocfg v1.1.0
   Compiling memchr v2.5.0
   Compiling libc v0.2.126
   Compiling syn v1.0.96
   Compiling glob v0.3.0
   Compiling cfg-if v1.0.0
   Compiling serde_derive v1.0.137
   Compiling log v0.4.17
   Compiling termcolor v1.1.3
   Compiling minimal-lexical v0.2.1
   Compiling regex-syntax v0.6.26
   Compiling os_str_bytes v6.1.0
   Compiling serde v1.0.137
   Compiling hashbrown v0.11.2
   Compiling bindgen v0.60.1
   Compiling either v1.6.1
   Compiling textwrap v0.15.0
   Compiling serde_json v1.0.81
   Compiling strsim v0.10.0
   Compiling bitflags v1.3.2
   Compiling humantime v2.1.0
   Compiling semver v1.0.9
   Compiling ryu v1.0.10
   Compiling rustc-hash v1.1.0
   Compiling peeking_take_while v0.1.2
   Compiling lazy_static v1.4.0
   Compiling itoa v1.0.2
   Compiling lazycell v1.3.0
   Compiling shlex v1.1.0
   Compiling byteorder v1.4.3
   Compiling cty v0.2.2
   Compiling shlex v0.1.1
   Compiling nb v1.0.0
   Compiling c2rust-asm-casts v0.2.0
   Compiling stable_deref_trait v1.2.0
   Compiling void v1.0.2
   Compiling mutex-trait v0.2.0
   Compiling bare-metal v1.0.0
   Compiling pin-utils v0.1.0
   Compiling hex v0.4.3
   Compiling rust_riotmodules v0.1.0 (/tmp/dwq.0.828799345211067/1d1268c526f23e2d84dbe3f5848970a9/sys/rust_riotmodules)
   Compiling libloading v0.7.3
   Compiling clap_lex v0.2.0
   Compiling nb v0.1.3
   Compiling hash32 v0.2.1
   Compiling embedded-graphics v0.6.2
   Compiling indexmap v1.8.2
   Compiling num-traits v0.2.15
   Compiling riot-wrappers v0.7.22 (https://github.com/RIOT-OS/rust-riot-wrappers#bc6183f0)
   Compiling embedded-hal v0.2.7
   Compiling clang-sys v1.3.3
   Compiling cstr_core v0.2.6
   Compiling rustc_version v0.4.0
   Compiling aho-corasick v0.7.18
   Compiling nom v7.1.1
   Compiling quote v1.0.18
   Compiling heapless v0.7.13
   Compiling atty v0.2.14
   Compiling which v4.2.5
   Compiling clap v3.1.18
   Compiling regex v1.5.6
   Compiling cexpr v0.6.0
   Compiling env_logger v0.9.0
   Compiling c2rust-bitfields-derive v0.2.1
   Compiling c2rust-bitfields v0.3.0
   Compiling riot-sys v0.7.7 (https://github.com/RIOT-OS/rust-riot-sys#c7e6e9e8)
error[E0425]: cannot find function `mutex_lock` in crate `riot_sys`
  --> /data/riotbuild/.cargo/git/checkouts/rust-riot-wrappers-155be8faf0b21fa1/bc6183f/src/mutex.rs:45:28
   |
45 |         unsafe { riot_sys::mutex_lock(crate::inline_cast_mut(self.mutex.get())) };
   |                            ^^^^^^^^^^
   |
  ::: /tmp/dwq.0.828799345211067/1d1268c526f23e2d84dbe3f5848970a9/build/target/thumbv7m-none-eabi/release/build/riot-sys-ee3ae4161c94057e/out/bindings.rs:3:699110
   |
3  | ...ust not be NULL."] pub fn rmutex_lock (rmutex : * mut rmutex_t) ; } extern "C" { # [doc = " @brief Unlocks the recursive mutex."] # [d...
   |                       -------------------------------------------- similarly named function `rmutex_lock` defined here
   |
help: a function with a similar name exists
   |
45 |         unsafe { riot_sys::rmutex_lock(crate::inline_cast_mut(self.mutex.get())) };
   |                            ~~~~~~~~~~~
help: consider importing this function
   |
8  | use riot_sys::inline::mutex_lock;
   |
help: if you import `mutex_lock`, refer to it directly
   |
45 -         unsafe { riot_sys::mutex_lock(crate::inline_cast_mut(self.mutex.get())) };
45 +         unsafe { mutex_lock(crate::inline_cast_mut(self.mutex.get())) };
   |

For more information about this error, try `rustc --explain E0425`.
error: could not compile `riot-wrappers` due to previous error
warning: build failed, waiting for other jobs to finish...
make: *** [/tmp/dwq.0.828799345211067/1d1268c526f23e2d84dbe3f5848970a9/makefiles/cargo-targets.inc.mk:44: /tmp/dwq.0.828799345211067/1d1268c526f23e2d84dbe3f5848970a9/build/target/thumbv7m-none-eabi/release/librust_hello_world.a] Error 101
make: Leaving directory '/tmp/dwq.0.828799345211067/1d1268c526f23e2d84dbe3f5848970a9/examples/rust-hello-world'
cat: /tmp/dwq.0.828799345211067/1d1268c526f23e2d84dbe3f5848970a9/build/test-input-hash.sha1: No such file or directory
{"build/": 263124}

I'll abort the CI run now, so that the other jobs have a chance to get through until tomorrow

chrysn · 2022-09-22T19:54:34Z

Yes; last time I checked, the functions would have kept their staticness (but maybe I missed it). It's one of these things where the bindings are stricter than C when it comes to API stability. There is a mechanism for "it's OK that this function may be static-inline or not" in the -sys crate, I'll look into updating it.

chrysn · 2022-09-22T20:07:20Z

I've pushed a fix, and added a branch switch to try out the fix on this branch. If this builds fine, I'll merge RIOT-OS/rust-riot-sys#10.

maribu · 2022-09-23T13:03:36Z

I threw in an unrelated fix and a commit to limit the build to (one of) the app the failed building due to the API change from rust's point of view

This restores a pre-existing design decision to implement both blocking and non-blocking mutex locking with the same code. Those implementations have been split prior to the introduction of the `core_mutex_priority_inheritance` module when `mutex_trylock()` indeed was trivial. This decision didn't age well, so undo it.

maribu · 2022-10-02T19:13:49Z

Finally, all green. Technically a second ACK is still needed.

chrysn

Looks good to me as well.

chrysn · 2022-10-03T05:34:15Z

core/include/mutex.h

+#if (MAXTHREADS > 1)
+    mutex_lock_internal(mutex, true);
+#else
+    /* dummy implementation for when no scheduler is used */
    /* (ab)use next pointer as lock variable */
    volatile uintptr_t *lock = (void *)&mutex->queue.next;


I'm unsure whether volatile has the right semantics for this (it does guarantee that the write is made, but does it ensure the ordering relative to other operations on memory?), but that's not a thing that needs to be addressed here.

this is indeed another misuse of volatile. Previously they seemed to "fix" things because irq_disable() and irq_restore() did not include compiler memory barriers, but the corresponding inline asm was also marked as volatile. I am quite sure that the actual bugs are fixed for all platforms now, so that this workaround should be dropped now. But that is something for a different PR IMO

maribu · 2022-10-03T10:35:36Z

thx :)

18620: core: add core_mutex_debug to aid debugging deadlocks r=benpicco a=maribu ### Contribution description Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in on log messages such as [mutex] waiting for thread 1 (pc = 0x800024d) being added whenever `mutex_lock()` blocks. This makes tracing down deadlocks easier. ### Testing procedure Run e.g. ```sh USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test ``` which should provide output such as ``` Welcome to pyterm! Type '/exit' to exit. READY s [mutex] waiting for thread 1 (pc = 0x8000f35) START main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug) Test Application for mutex_cancel / mutex_lock_cancelable ========================================================= Test without cancellation: OK Test early cancellation: OK Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d) OK Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0) OK TEST PASSED ``` ```sh $ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf 0x0800024d /home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51 ``` ### Issues/PRs references Depends on and includes #18619 19296: nanocoap: allow to define CoAP resources as XFA r=benpicco a=benpicco 19504: cpu/cc26xx_cc13xx: Fix bogus array-bound warning r=benpicco a=maribu ### Contribution description GCC 12 create a bogus array out of bounds warning as it assumes that because there is special handling for `uart == 0` and `uart == 1`, `uart` can indeed be `1`. There is an `assert(uart < UART_NUMOF)` above that would blow up prior to any out of bounds access. In any case, optimizing out the special handling of `uart == 1` for when `UART_NUMOF == 1` likely improves the generated code and fixes the warning. /home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:88:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds] 88 | ctx[uart].rx_cb = rx_cb; | ~~~^~~~~~ /home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx' 52 | static uart_isr_ctx_t ctx[UART_NUMOF]; | ^~~ /home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:89:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds] 89 | ctx[uart].arg = arg; | ~~~^~~~~~ /home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx' 52 | static uart_isr_ctx_t ctx[UART_NUMOF]; | ^~~ ### Testing procedure The actual change is a pretty obvious one-liner, so that code review and a green CI should be sufficient. If not, running any UART example app without regression should do. ### Issues/PRs references None 19506: tools/openocd: Fix handling of OPENOCD_CMD_RESET_HALT r=maribu a=maribu ### Contribution description The OPENOCD_CMD_RESET_HALT was not longer correctly passed to the script. This fixes the issue. ### Testing procedure Flashing of e.g. the `cc2650-launchpad` with upstream OpenOCD should work again. ### Issues/PRs references The change was added to #19050 after testing the PR and before merging. I'm not sure if the fix never worked because of this, or if behavior of `target-export-variables` or GNU Make changed. 19507: cpu/cc26x0_cc13x0: Drop feature cortexm_mpu r=benpicco a=maribu ### Contribution description At least the CC2650 doesn't have an MPU, I assume this is also true for the rest of the family. The CC2652 does have an MPU according to the datasheet. So I keep the feature there in place. ### Testing procedure E.g. ``` make BOARD=cc2650-launchpad -C tests/mpu_noexec_ram flash test ``` fails. (Note: A successful test run would also crash but with a mem manage handler rather than a hardfault due to an invalid instruction on the stack being executed.) It would be nice to also test the same for a `cc2652-launchpad`, for which the MPU should work. ### Issues/PRs references None Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de> Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de> Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>

18620: core: add core_mutex_debug to aid debugging deadlocks r=benpicco a=maribu ### Contribution description Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in on log messages such as [mutex] waiting for thread 1 (pc = 0x800024d) being added whenever `mutex_lock()` blocks. This makes tracing down deadlocks easier. ### Testing procedure Run e.g. ```sh USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test ``` which should provide output such as ``` Welcome to pyterm! Type '/exit' to exit. READY s [mutex] waiting for thread 1 (pc = 0x8000f35) START main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug) Test Application for mutex_cancel / mutex_lock_cancelable ========================================================= Test without cancellation: OK Test early cancellation: OK Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d) OK Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0) OK TEST PASSED ``` ```sh $ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf 0x0800024d /home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51 ``` ### Issues/PRs references Depends on and includes #18619 19296: nanocoap: allow to define CoAP resources as XFA r=benpicco a=benpicco Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de> Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de> Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>

18620: core: add core_mutex_debug to aid debugging deadlocks r=maribu a=maribu ### Contribution description Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in on log messages such as [mutex] waiting for thread 1 (pc = 0x800024d) being added whenever `mutex_lock()` blocks. This makes tracing down deadlocks easier. ### Testing procedure Run e.g. ```sh USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test ``` which should provide output such as ``` Welcome to pyterm! Type '/exit' to exit. READY s [mutex] waiting for thread 1 (pc = 0x8000f35) START main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug) Test Application for mutex_cancel / mutex_lock_cancelable ========================================================= Test without cancellation: OK Test early cancellation: OK Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d) OK Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0) OK TEST PASSED ``` ```sh $ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf 0x0800024d /home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51 ``` ### Issues/PRs references Depends on and includes #18619 Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>

18620: core: add core_mutex_debug to aid debugging deadlocks r=maribu a=maribu ### Contribution description Adding `USEMODULE += core_mutex_debug` to your `Makefile` results in on log messages such as [mutex] waiting for thread 1 (pc = 0x800024d) being added whenever `mutex_lock()` blocks. This makes tracing down deadlocks easier. ### Testing procedure Run e.g. ```sh USEMODULE=core_mutex_debug BOARD=nucleo-f767zi make -C tests/mutex_cancel flash test ``` which should provide output such as ``` Welcome to pyterm! Type '/exit' to exit. READY s [mutex] waiting for thread 1 (pc = 0x8000f35) START main(): This is RIOT! (Version: 2022.10-devel-841-g5cc02-core/mutex/debug) Test Application for mutex_cancel / mutex_lock_cancelable ========================================================= Test without cancellation: OK Test early cancellation: OK Verify no side effects on subsequent calls: [mutex] waiting for thread 1 (pc = 0x800024d) OK Test late cancellation: [mutex] waiting for thread 1 (pc = 0x0) OK TEST PASSED ``` ```sh $ arm-none-eabi-addr2line -a 0x800024d -e tests/mutex_cancel/bin/nucleo-f767zi/tests_mutex_cancel.elf 0x0800024d /home/maribu/Repos/software/RIOT/tests/mutex_cancel/main.c:51 ``` ### Issues/PRs references Depends on and includes #18619 19296: nanocoap: allow to define CoAP resources as XFA r=maribu a=benpicco 19504: cpu/cc26xx_cc13xx: Fix bogus array-bound warning r=maribu a=maribu ### Contribution description GCC 12 create a bogus array out of bounds warning as it assumes that because there is special handling for `uart == 0` and `uart == 1`, `uart` can indeed be `1`. There is an `assert(uart < UART_NUMOF)` above that would blow up prior to any out of bounds access. In any case, optimizing out the special handling of `uart == 1` for when `UART_NUMOF == 1` likely improves the generated code and fixes the warning. /home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:88:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds] 88 | ctx[uart].rx_cb = rx_cb; | ~~~^~~~~~ /home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx' 52 | static uart_isr_ctx_t ctx[UART_NUMOF]; | ^~~ /home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:89:8: error: array subscript 1 is above array bounds of 'uart_isr_ctx_t[1]' [-Werror=array-bounds] 89 | ctx[uart].arg = arg; | ~~~^~~~~~ /home/maribu/Repos/software/RIOT/cc2650/cpu/cc26xx_cc13xx/periph/uart.c:52:23: note: while referencing 'ctx' 52 | static uart_isr_ctx_t ctx[UART_NUMOF]; | ^~~ ### Testing procedure The actual change is a pretty obvious one-liner, so that code review and a green CI should be sufficient. If not, running any UART example app without regression should do. ### Issues/PRs references None 19506: tools/openocd: Fix handling of OPENOCD_CMD_RESET_HALT r=maribu a=maribu ### Contribution description The OPENOCD_CMD_RESET_HALT was not longer correctly passed to the script. This fixes the issue. ### Testing procedure Flashing of e.g. the `cc2650-launchpad` with upstream OpenOCD should work again. ### Issues/PRs references The change was added to #19050 after testing the PR and before merging. I'm not sure if the fix never worked because of this, or if behavior of `target-export-variables` or GNU Make changed. Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de> Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de> Co-authored-by: Benjamin Valentin <benjamin.valentin@ml-pa.com>

maribu requested a review from kaspar030 as a code owner September 21, 2022 11:20

maribu mentioned this pull request Sep 21, 2022

core: add core_mutex_debug to aid debugging deadlocks #18620

Merged

maribu commented Sep 21, 2022

View reviewed changes

maribu force-pushed the core/mutex/cleanup branch from 5cc0244 to f367ea4 Compare September 21, 2022 12:57

benpicco reviewed Sep 21, 2022

View reviewed changes

core/mutex.c Show resolved Hide resolved

maribu force-pushed the core/mutex/cleanup branch from 9f593b3 to 5ff92dc Compare September 21, 2022 13:11

benpicco approved these changes Sep 21, 2022

View reviewed changes

maribu force-pushed the core/mutex/cleanup branch from 5ff92dc to 2be434e Compare September 21, 2022 13:17

benpicco reviewed Sep 21, 2022

View reviewed changes

maribu force-pushed the core/mutex/cleanup branch from 2be434e to ce88f86 Compare September 22, 2022 11:43

maribu requested a review from fjmolinas as a code owner September 22, 2022 11:43

github-actions bot added Area: cpu Area: CPU/MCU ports Area: sys Area: System labels Sep 22, 2022

maribu removed the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Sep 22, 2022

chrysn mentioned this pull request Sep 22, 2022

build: Add mutex_lock to inline-or-not list RIOT-OS/rust-riot-sys#10

Merged

chrysn added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Sep 22, 2022

chrysn mentioned this pull request Sep 23, 2022

makefiles: Rust fixes and info extensions #18630

Merged

github-actions bot added Area: drivers Area: Device drivers Area: CI Area: Continuous Integration of RIOT components labels Sep 23, 2022

maribu added 2 commits September 26, 2022 18:54

drivers/sgp30: add missing include

3f882cb

drivers/sm_pwm_01c: add missing include

d1ecc51

maribu force-pushed the core/mutex/cleanup branch from 7006724 to 243e38d Compare September 26, 2022 16:54

tests/periph_gpio_ll: add missing include

96d982f

maribu force-pushed the core/mutex/cleanup branch from 243e38d to 0055484 Compare September 28, 2022 15:59

maribu requested review from smlng, leandrolanzieri, aabadie and MichelRottleuthner as code owners September 28, 2022 15:59

github-actions bot added the Area: tests Area: tests and testing framework label Sep 28, 2022

maribu added 2 commits September 29, 2022 13:12

pkg/driver_bme680: add missing include

8800ba3

maribu force-pushed the core/mutex/cleanup branch from 0055484 to 2d2bb4b Compare September 29, 2022 11:12

github-actions bot added the Area: pkg Area: External package ports label Sep 29, 2022

chrysn approved these changes Oct 3, 2022

View reviewed changes

maribu added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Oct 3, 2022

maribu enabled auto-merge October 3, 2022 06:54

maribu merged commit 3227fb3 into RIOT-OS:master Oct 3, 2022

maribu deleted the core/mutex/cleanup branch October 3, 2022 10:35

maribu added this to the Release 2022.10 milestone Oct 14, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

core/mutex: clean up #18619

core/mutex: clean up #18619

maribu commented Sep 21, 2022

benpicco commented Sep 21, 2022

chrysn commented Sep 21, 2022

maribu Sep 21, 2022

maribu commented Sep 21, 2022

benpicco Sep 21, 2022 •

edited

Loading

benpicco Sep 28, 2022

benpicco Sep 29, 2022

maribu commented Sep 22, 2022 •

edited

Loading

chrysn commented Sep 22, 2022

chrysn commented Sep 22, 2022

maribu commented Sep 23, 2022

maribu commented Oct 2, 2022

chrysn left a comment

chrysn Oct 3, 2022

maribu Oct 3, 2022

maribu commented Oct 3, 2022

core/mutex: clean up #18619

core/mutex: clean up #18619

Conversation

maribu commented Sep 21, 2022

Contribution description

Testing procedure

Issues/PRs references

benpicco commented Sep 21, 2022

chrysn commented Sep 21, 2022

maribu Sep 21, 2022

Choose a reason for hiding this comment

maribu commented Sep 21, 2022

benpicco Sep 21, 2022 • edited Loading

Choose a reason for hiding this comment

benpicco Sep 28, 2022

Choose a reason for hiding this comment

benpicco Sep 29, 2022

Choose a reason for hiding this comment

maribu commented Sep 22, 2022 • edited Loading

chrysn commented Sep 22, 2022

chrysn commented Sep 22, 2022

maribu commented Sep 23, 2022

maribu commented Oct 2, 2022

chrysn left a comment

Choose a reason for hiding this comment

chrysn Oct 3, 2022

Choose a reason for hiding this comment

maribu Oct 3, 2022

Choose a reason for hiding this comment

maribu commented Oct 3, 2022

benpicco Sep 21, 2022 •

edited

Loading

maribu commented Sep 22, 2022 •

edited

Loading