mastodontech.de ist einer von vielen unabhängigen Mastodon-Servern, mit dem du dich im Fediverse beteiligen kannst.
Offen für alle (über 16) und bereitgestellt von Markus'Blog

Serverstatistik:

1,5 Tsd.
aktive Profile

#lockfree

1 Beitrag1 Beteiligte*r0 Beiträge heute
Felix Palmen :freebsd: :c64:<p>Please help me spread the link to <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> 😎</p><p><a href="https://github.com/Zirias/swad" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">github.com/Zirias/swad</span><span class="invisible"></span></a></p><p>I really need some users by now, for those two reasons:</p><p>* I'm at a point where I fully covered my own needs (the reasons I started coding this), and getting some users is the only way to learn about what other people might need<br>* The complexity "exploded" after supporting so many OS-specific APIs (like <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>kqueue</span></a>, <a href="https://mastodon.bsd.cafe/tags/epoll" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>epoll</span></a>, <a href="https://mastodon.bsd.cafe/tags/eventfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>eventfd</span></a>, <a href="https://mastodon.bsd.cafe/tags/signalfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>signalfd</span></a>, <a href="https://mastodon.bsd.cafe/tags/timerfd" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>timerfd</span></a>, <a href="https://mastodon.bsd.cafe/tags/eventports" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>eventports</span></a>) and several <a href="https://mastodon.bsd.cafe/tags/lockfree" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>lockfree</span></a> implementations based on <a href="https://mastodon.bsd.cafe/tags/atomics" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>atomics</span></a> while still providing fallbacks for everything that *should* work on any <a href="https://mastodon.bsd.cafe/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>POSIX</span></a> systems ... I'm definitely unable at this point to think of every possible edge case and test it. If there are <a href="https://mastodon.bsd.cafe/tags/bugs" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>bugs</span></a> left (which is somewhat likely), I really need people reporting these to me</p><p>Thanks! 🙃</p>
Felix Palmen :freebsd: :c64:<p>This redesign of <a href="https://mastodon.bsd.cafe/tags/poser" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>poser</span></a> (for <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a>) to offer a "multi-reactor" (with multiple <a href="https://mastodon.bsd.cafe/tags/threads" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>threads</span></a> running each their own event loop) starts to give me severe headaches.</p><p>There is *still* a very rare data <a href="https://mastodon.bsd.cafe/tags/race" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>race</span></a> in the <a href="https://mastodon.bsd.cafe/tags/lockfree" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>lockfree</span></a> <a href="https://mastodon.bsd.cafe/tags/queue" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>queue</span></a>. 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-&gt;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-&gt;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. 🤯 </p><p>Please tell me whether I have an error in my thinking here. Can it be ....? 🤔 </p><p>Meanwhile, after fixing and improving lots of things, I checked the alternative implementation using <a href="https://mastodon.bsd.cafe/tags/mutexes" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mutexes</span></a> 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 <a href="https://mastodon.bsd.cafe/tags/atomics" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>atomics</span></a> stuff again and just go with mutexes.</p><p>[1] <a href="https://dl.acm.org/doi/10.1145/248052.248106" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">dl.acm.org/doi/10.1145/248052.</span><span class="invisible">248106</span></a></p>
Felix Palmen :freebsd: :c64:<p>More interesting progress trying to make <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> suitable for very busy sites!</p><p>I realized that <a href="https://mastodon.bsd.cafe/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> (both with <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a> and <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a>) 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 <a href="https://mastodon.bsd.cafe/tags/lockfree" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>lockfree</span></a> queue as opposed to one protected by a <a href="https://mastodon.bsd.cafe/tags/mutex" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mutex</span></a>. 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. 😆</p><p>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.</p><p>Open issue: Can I do something about TLS? There *must* be some way to make it perform at least a *bit* better...</p><p>(*) 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: <a href="https://dl.acm.org/doi/10.1145/248052.248106" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">dl.acm.org/doi/10.1145/248052.</span><span class="invisible">248106</span></a></p>
Felix Palmen :freebsd: :c64:<p>Getting somewhat closer to releasing a new version of <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a>. I now improved the functionality to execute something on a different worker thread: Use an in-memory queue, providing a <a href="https://mastodon.bsd.cafe/tags/lockfree" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>lockfree</span></a> version. This gives me a consistent reliable throughput of 3000 requests/s (with outliers up to 4500 r/s) at an average response time of 350 - 400 ms (with TLS enabled). For waking up worker threads, I implemented different backends as well: kqueue, eventfd and event-ports, the fallback is still a self-pipe.</p><p>So, <a href="https://mastodon.bsd.cafe/tags/portability" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>portability</span></a> here really means implement lots of different flavors of the same thing.</p><p>Looking at these startup logs, you can see that <a href="https://mastodon.bsd.cafe/tags/kqueue" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>kqueue</span></a> (<a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>FreeBSD</span></a> and other BSDs) is really a "jack of all trades", being used for "everything" if available (and that's pretty awesome, it means one single <a href="https://mastodon.bsd.cafe/tags/syscall" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>syscall</span></a> per event loop iteration in the generic case). <a href="https://mastodon.bsd.cafe/tags/illumos" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>illumos</span></a>' (<a href="https://mastodon.bsd.cafe/tags/Solaris" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Solaris</span></a>) <a href="https://mastodon.bsd.cafe/tags/eventports" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>eventports</span></a> come somewhat close (but need a lot more syscalls as there's no "batch registering" and certain event types need to be re-registered every time they fired), they just can't do signals, but illumos offers Linux-compatible signalfd. Looking at <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Linux</span></a>, there's a "special case fd" for everything. 🙈 Plus <a href="https://mastodon.bsd.cafe/tags/epoll" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>epoll</span></a> also needs one syscall for each event to be registered. The "generic <a href="https://mastodon.bsd.cafe/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>POSIX</span></a>" case without any of these interfaces is just added for completeness 😆</p>
Hacker News<p>Ruby, Ractors, and Lock-Free Data Structures</p><p><a href="https://iliabylich.github.io/ruby-ractors-and-lock-free-data-structures/" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">iliabylich.github.io/ruby-ract</span><span class="invisible">ors-and-lock-free-data-structures/</span></a></p><p><a href="https://mastodon.social/tags/HackerNews" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>HackerNews</span></a> <a href="https://mastodon.social/tags/Ruby" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Ruby</span></a> <a href="https://mastodon.social/tags/Ractors" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Ractors</span></a> <a href="https://mastodon.social/tags/LockFree" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LockFree</span></a> <a href="https://mastodon.social/tags/DataStructures" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DataStructures</span></a> <a href="https://mastodon.social/tags/ProgrammingConcurrency" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ProgrammingConcurrency</span></a></p>