Mastodawn

Medicinart capsule 017/446 Title: Waiting in a Q
#art #analogue #handmade #noai #pocketsized #healing #queue #waiting #mixedmedia #q

Hacker News Jun 28

A Go service that exposes a FIFO message queue in RAM

https://github.com/raiyanyahya/zapq

#HackerNews #Go #FIFO #RAM #Queue #GoLang #MessageQueue #TechInnovation

GitHub - raiyanyahya/zapq: ⚡ A single‑binary Go microservice that exposes a First‑In First‑Out message queue completely in RAM.

⚡ A single‑binary Go microservice that exposes a First‑In First‑Out message queue completely in RAM. - GitHub - raiyanyahya/zapq: ⚡ A single‑binary Go microservice that exposes a First‑In First‑Ou...

GitHub

Show thread

Rochelle K Jun 19

TikTok star Spud Man and his queue at the 2025 Suffolk Show [Day 2] (29/05/2025) [2]

Note: I have some conditions when it comes to my photography works, please read here: https://www.facebook.com/RochelleK1994/posts/pfbid034Bv2emjgf6iNoUZnATQajyzbyuGmvickuQ5rTKbCzHiiwkyQxsTKCQBTDpEP2TCnl

#photography #photographer #britishphotographer #suffolkphotographer #creativephotographer #photographyisart #eventphotography #foodvendor #spudman #spudarmy #queue #suffolkshow #suffolkshow2025 #trinitypark #ipswich #suffolk #eastanglia #eastofengland

Rochelle K Jun 19

TikTok star Spud Man, his jacket potato and his queue at the 2025 Suffolk Show [Day 2] (29/05/2025) [1]

Note: I have some conditions for my photography works, please read here: https://www.facebook.com/RochelleK1994/posts/pfbid034Bv2emjgf6iNoUZnATQajyzbyuGmvickuQ5rTKbCzHiiwkyQxsTKCQBTDpEP2TCnl

#photography #photographer #britishphotographer #photographyisart #macrophotography #macro #eventphotography #foodphotography #food #foodvendor #spudman #spudarmy #potato #jacketpotato #jacketspud #queue #suffolkshow #suffolkshow2025 #trinitypark #ipswich #suffolk #eastanglia #eastofengland

Show thread

Felix Palmen

Jun 13

The #lockfree command #queue in #poser (for #swad) is finally fixed!

The original algorithm from [MS96] works fine *only* if the "free" function has some "magic" in place to defer freeing the object until no thread holds a reference any more ... and that magic is, well, left as an exercise to the reader. 🙈

Doing more research, I found a few suggestions how to do that "magic", including for example #hazardpointers ... but they're known to cause quite some runtime overhead, so not really an option. I decided to implement some "shared object manager" based on the ideas from [WICBS18], which is kind of a "manually triggered garbage collector" in the end. And hey, it works! 🥳
https://github.com/Zirias/poser/blob/master/src/lib/core/sharedobj.c

[MS96] https://dl.acm.org/doi/10.1145/248052.248106
[WICBS18] https://www.cs.rochester.edu/u/scott/papers/2018_PPoPP_IBR.pdf

#coding #c #c11 #atomics

poser/src/lib/core/sharedobj.c at master · Zirias/poser

POsix SERvices framework for C. Contribute to Zirias/poser development by creating an account on GitHub.

GitHub

Felix Palmen

Jun 11

This redesign of #poser (for #swad) to offer a "multi-reactor" (with multiple #threads running each their own event loop) starts to give me severe headaches.

There is *still* a very rare data #race in the #lockfree #queue. I *think* I can spot it in the pseudo code from the paper I used[1], see screenshot. Have a look at lines E7 and E8. Suppose the thread executing this is suspended after E7 for a "very long time". Now, some dequeue operation from some other thread will eventually dequeue whatever "Q->Tail" was pointing to, and then free it after consumption. Our poor thread resumes, checks the pointer already read in E6 for NULL successfully, and then tries a CAS on tail->next in E9, which is unfortunately inside an object that doesn't exist any more .... If the CAS succeeds because at this memory location happens to be "zero" bytes, we corrupted some random other object that might now reside there. 🤯

Please tell me whether I have an error in my thinking here. Can it be ....? 🤔

Meanwhile, after fixing and improving lots of things, I checked the alternative implementation using #mutexes again, and surprise: Although it's still a bit slower, the difference is now very very small. And it has the clear advantage that it never crashes. 🙈 I'm seriously considering to drop all the lock-free #atomics stuff again and just go with mutexes.

[1] https://dl.acm.org/doi/10.1145/248052.248106

Show thread

Felix Palmen

Jun 11

I guess this funny looking graph showing response time percentiles is exactly the result of one of 8 service worker threads having a lot more to do than all others. I wonder whether this could be a behavioral artifact of the #lockfree #queue used to distribute the accepted connections. 🤔