Behold, the latest masterpiece for those who dream of locking their #bash scripts in eternal embrace with a mutex! Because who doesn't love making the simplest tasks into a cryptic #semaphore puzzle? Meanwhile, #GitHub casually hints that #AI should write your code, perhaps after it untangles this weave of command line wizardry.
https://github.com/bigattichouse/waitlock #scripting #mutex #coding #HackerNews #ngated

Linux CLI tool to provide mutex locks for long running bash ops

https://github.com/bigattichouse/waitlock

Short stop at @devconf_cz 2025! Always great to meet @toke of #FQ_CoDel (#RFC8290) & #sch_CAKE fame

Check out his talk “Beware of the #kernel RTNL #mutex”:

https://pretalx.devconf.info/devconf-cz-2025/talk/WQDUDJ/

More interesting progress trying to make #swad suitable for very busy sites!

I realized that #TLS (both with #OpenSSL and #LibreSSL) is a *major* bottleneck. With TLS enabled, I couldn't cross 3000 requests per second, with somewhat acceptable response times (most below 500ms). Disabling TLS, I could really see the impact of a #lockfree queue as opposed to one protected by a #mutex. With the mutex, up to around 8000 req/s could be reached on the same hardware. And with a lockfree design, that quickly went beyond 10k req/s, but crashed.

So I read some scientific papers ... and redesigned a lot (*). And now it finally seems to work. My latest test reached a throughput of almost 25k req/s, with response times below 10ms for most requests! I really didn't expect to see *this* happen. Maybe it could do even more, didn't try yet.

Open issue: Can I do something about TLS? There *must* be some way to make it perform at least a *bit* better...

(*) edit: Here's the design I finally used, with a much simplified "dequeue" because the queues in question are guaranteed to have only a single consumer: https://dl.acm.org/doi/10.1145/248052.248106

I recently took a dive into #C11 #atomics to come up with alternative queue implementations not requiring locking some #mutex.

TBH, I have a hard time understanding the #memory #ordering constraints defined by C11. I mean, I code #assembler on a #mos6502 (for the #c64), so caches, pipelines and all that modern crap is kind of alien rocket science anyways .

But seriously, they try to abstract from what the hardware provides (different kinds of memory barrier instructions, IMHO somewhat easier to understand), so the compiler can pick the appropriate one depending on the target CPU. But wrapping your head around their definition really hurts the brain .

Yesterday, I found a source telling me that #amd64 (or #x86 in general?) always has strong ordering for reads, so no matter which oderding constraint you put in your atomic_load and friends, the compiler will generate the same code and it will work. Oh boy, how should I ever verify my code works on e.g. aarch64 without owning such hardware?

Some brave soul decided to reinvent the wheel by building their own #mutex in C, because, apparently, mastering pre-existing solutions just wasn't challenging (or fun) enough. Instead of taking a nice walk outside, they've chosen to dance with futexes, as if Linux needed more accidental 'optimizations.'
https://blog.fredrb.com/2025/06/02/futex-fun/ #reinventthewheel #Cprogramming #futex #Linuxoptimization #codinghumor #HackerNews #ngated

Nice read! @mamantoha published a short and nice blog post about #semaphores in @CrystalLanguage at @thepracticaldev:

https://dev.to/mamantoha/semaphores-in-crystal-5eha

Los mutex permiten solucionar el problema de las race condition en programación concurrente. En este articulo te explico como usarlos correctamente.

https://www.lateclaescape.com/post/2025/mutex/

A quick question for #Arduino enthusiasts: Have you ever used the #FreeRTOS #API? Were you satisfied with it? I tested the #MP #Mutex API from #Spresense and found it quite clear and easy to use.

Think I solved why my inside Docker (ROS 2) access to I2C INA219 current sensor was colliding with my outside Docker access to the device - forgot to map the /var/lock directory so the mutex is visible from both environments!

Make Your Code Slower With Multithreading https://hackaday.com/2024/06/07/make-your-code-slower-with-multithreading/ #MULTITHREADING #SoftwareHacks #performance #profiling #spinlocks #syscall #futex #mutex #Perf+

Make Your Code Slower With Multithreading - With the performance of modern CPU cores plateauing recently, the main performance... - https://hackaday.com/2024/06/07/make-your-code-slower-with-multithreading/ #multithreading #softwarehacks #performance #profiling #spinlocks #syscall #futex #mutex #perf

#tui #daw for #jack in #rustlang

Rewrote the UI of the #midi sequencer with #ratatui for double buffering.

We're polyphonic now! Multithreaded, too - I put a #mutex between input/render/audio threads instead of message passing.

Doesn't even properly support Note Off events yet, but it does play a mean cheerful dirge. Playback cursor position still off, though.

Hooking this up to the VST host every time I restart either is bit of a faff. Gotta teach it to auto-connect the MIDI/audio ports...

Debugging lock ordering inversions

Kotlin Mutex: A Comprehensive Guide

#koltin #mutex

https://medium.com/@dugguRK/kotlin-mutex-a-comprehensive-guide-5771a3f59713?utm_medium=erik.in&utm_source=mastodon

Using ThreadSanitizer in OCaml https://tarides.com/blog/2023-10-18-off-to-the-races-using-threadsanitizer-in-ocaml/ #Multicore #OCaml #Compiler #Mutex @tarides_