Recent posts - Tue, 11 May 2021 07:55:32 +0000 esoTalk orent - waiting for elements <p>The lowest overhead option available on linux that does involve the kernel is a futex. It is absolutely the fastest form of inter-process communication capable of waking up a sleeping thread/process. It is also quite compatible with the concepts of lock-free programming as it waits for a memory location to be not equal to a specific value, which helps avoid missed wakeups and other issues. A futex notify can notify one or all waiters. A short polling loop with a fallback to futex is often a good idea. One tricky point is that a futex is always 32 bits, even on a 64 bit platform.</p><p>A zero kernel wakeup solution would have to be tightly integrated with your user-mode thread library.</p> Tue, 11 May 2021 07:55:32 +0000 admin - any plans for ARM64 ? <p>Good evening, Alex.</p><p>I&#39;ve been writing a book for the last year and a half, which is why liblfds has seen no releases for a long time.</p><p>There&#39;s a great deal of unreleased development work, which is really annoying!</p><p>I&#39;ve also acquired a RISC-V dev board, which was 1300 USD, which is pretty good proof of ongoing interest :-)</p><p>I&#39;m working now to get some initial material released from the book. It might be I take some time to get a new released of liblfds out once that is done - I&#39;d love to do so; I&#39;m very unhappy that even ARM64 support isn&#39;t out, which is obviously a huge capability gap.</p> Sun, 20 Sep 2020 20:27:11 +0000 Alex Lovushkin - any plans for ARM64 ? <p>Неllo, admin. I would like to ask the same question about ARM64 support. Now we are loocking for lock-free algo and structere lib (with ARM64 support) and liblfds seems to be very powerfull and convinient for our purposes. Unfortunately, we have not seen any dev progress in your repo. Could you please tell us if you are plannig to continue supporting this project in future and will there be any releases from you site?</p> Thu, 17 Sep 2020 10:40:33 +0000 admin - waiting for elements <p>A very good and question, which I spent some time trying to do something about, some years ago.</p><p>The basic problem is that the queue (and all the data structures) are running in user-mode, no switching to the kernel, which is one of the ways in which they are efficient. You absolutely do -not- want to be switching back to kernel mode to wait for a next element.</p><p>Problem then is how -do- you wait?</p><p>Turns out there&#39;s very little - almost no - support for user-mode waiting.</p><p>You can call yield(), but then you&#39;re kinda busy waiting.</p><p>Or maybe the OS has support for user-mode threads (Windows calls them fibers) and then you can control when threads sleep or run; but that still leaves you with the problem of knowing when a queue element has arrived. There&#39;s no user-mode event or semaphore or what-have-you.</p><p>So right now there *is* no proper, user-mode solution. You have to go to the OS, and you have to use a kernel-based blocking mechanism, where the sender writes to the queue and then triggers the listener(s) to wake up. Which sucks.</p> Sun, 30 Aug 2020 21:11:37 +0000 admin - ARM64 support <p>Just to let people know, fbous was at the time contacted directly by email and was sent the pre-release.</p> Sun, 30 Aug 2020 20:52:35 +0000 flok - waiting for elements <p>Hi,</p><p>What would be the appropriate way of waiting for elements to appear in a queue?</p><p>regards</p> Tue, 25 Aug 2020 12:16:15 +0000 fbous - ARM64 support <p>Hi,<br/>is it possible to get a pre-7.2 release drop so i can experiment with the ARM64 support?</p> Thu, 12 Dec 2019 18:15:10 +0000 admin - ringbuffer, with "LMAX Disruptor" semantics <p>Good evening.</p><p>I must apologise profusely for what must be the slowest reply I&#39;ve made in my life.</p><p>A number of other things have been on the go - I have to write a book and moving house *and* arranging a friend to come and stay for a couple of weeks - and I&#39;ve not checked the forum in a timely manner.</p><p>&gt; Liblfds has a ringbuffer implementation<br/>&gt; [snip]<br/>&gt; but its semantics is that of a queue at the reader&#39;s side</p><p>Yes. There can be many readers, but a single element can only be read by a single reader.</p><p>&gt; For our robotics and vision processing applications, we would prefer a different semantics, namely the one of the &quot;LMAX Disruptor&quot;</p><p>Do you mean *just* the ringbuffer from LMAX Disruptor, or the whole thing?</p><p>I&#39;ve had a look and found a document or two about their ringbuffer.</p><p>It appears to be the same design at the circular buffer used in the Linux kernel, but presumably modified to use atomic operations rather than only memory barriers (I looked at the source, but it was impenetrable at five minutes of examination).</p><p>That design is present in 7.1.1 in both forms.</p><p>The bounded, single producer, single consumer queue is this design using memory barriers only.</p><p>The bounded, many producer, many consumer queue is this design using atomic operations.</p><p>However, I have missed something here because the semantics remain queue-like for the reader.</p><p>Perhaps you&#39;re thinking of the LMAX DIsrupter as a whole, rather than just the ringbuffer?</p> Wed, 30 Jan 2019 23:41:08 +0000 bruyninc - ringbuffer, with "LMAX Disruptor" semantics <p>Liblfds has a ringbuffer implementation<br/> &lt;;<br/>but its semantics is that of a queue at the reader&#39;s side.</p><p>For our robotics and vision processing applications, we would prefer a different semantics,<br/>namely the one of the &quot;LMAX Disruptor&quot;<br/> &lt;;<br/> &lt;;</p><p>Is someone interested on discussing the design with us?<br/>Or maybe someone _has_ already some code that can be shared?</p><p>Would it be an acceptable addition to the project, to start with?</p><p>Best regards,</p><p>Herman Bruyninckx<br/>KU Leuven, Belgium</p> Fri, 11 Jan 2019 09:48:45 +0000 admin - any plans for ARM64 ? <p>Yes.</p><p>7.2.0 (next release) has ARM64. Supoprt was implemented over a year ago, I think - I have a PINE64 dev board, so I have hardware to test on, too.</p><p>I&#39;m currently working on the test and benchmark application - someone asked for a pre-release of some of the position-independent data structures (for use with shared memory, where the virtual memory ranges differ between processes) and I&#39;m adding the ability to spawn processes rather than just threads.</p><p>I&#39;m currently working, so I don&#39;t have much time. I&#39;ll be finished in eight weeks.</p><p>If you need ARM64 like *now*, I can drop you a pre-release now - drop me an email at admin at liblfds dot org.</p> Mon, 04 Jun 2018 20:01:34 +0000 fsynth - any plans for ARM64 ? <p>Hello,</p><p>just wondering, is there any plans for ARM64 support ?</p><p>Tried to port a software onto the Nano Pi NEO 2 today (without checking if the arch. was supported), all was compiled (GCC 5.4) but got a Segmentation fault at launch with gdb saying :</p><pre>0x000000000040fcfc in lfds711_freelist_push (fs=0x427000 &lt;rs&gt;, fe=0x45c510, psts=0x0) at ../../src/lfds711_freelist/lfds711_freelist_push.c:68 68 LFDS711_PAL_ATOMIC_DWCAS( fs-&gt;top, original_top, new_top, LFDS711_MISC_CAS_STRENGTH_WEAK, result );</pre><p>What is needed to port libflds to ARM64 ? … ok found the porting abstraction layer file which seem to be the one that need to be modified</p><p>Thank you for the great work on this library btw.</p> Thu, 31 May 2018 00:28:31 +0000 admin - Welcome to the sixth liblfds forum <p>Welcome to the forum.</p><p>There have been over the years changes in the forum software and it has never been possible to export conversations from one forum to another.</p><p>Account registration requires a captcha to be completed and then a confirmation URL is sent via email.</p> Mon, 26 Mar 2018 20:12:33 +0000