View source for r7.1.0:LFDS710 MISC FLUSH

{{DISPLAYTITLE:r7.1.0:LFDS710_MISC_FLUSH}}
==Source File==
 └───liblfds710
     └───inc
         └───liblfds710
                 lfds710_misc.h

==Define==
 #define LFDS710_MISC_FLUSH

==Notes==
This define is of critical importance to the correct operation, by users, of certain data structures in the library.

In general, in liblfds, the data structures are written such that by the time one of their functions returns, the operation performed by that function (enqueue, push, pop, etc) is both complete and visible to all other logical cores in the system.  However, two of the data structures, the bounded queues, are not like this; when their functions return, they guarantee the operation has occurred and is visible to the current logical core, but they do ''not'' guarantee that the operation is yet visible to all other logical cores in the system, and in fact there is no actual ''guarantee'' that it will ''ever'' be visible to other logical cores in the system, although in practise it's a bit like breathing - there's no actual guarantee you'll take your next breath, but usually, you always do :-)

In the spirit of Frankie Goes to Hollywood, these data structures are known as 'relaxed', because they just don't do it :-)

However, this behaviour causes problems when we come to cleanup such a data structure.  Since the thread performing the cleanup is not guaranteed to have seen all the operations performed by other threads - such as enqueues - it might be when it comes to cleanup, it simply can't yet see all the elements in the data structure.

The only way to solve this is this macro, ''LFDS710_MISC_FLUSH''.

The rule is that every thread which performs an operation on an instance of a relaxed data structure must call ''LFDS710_MISC_FLUSH'' before any thread can call the cleanup function of that instance.

On a lightly loaded system, and indeed particularly so with a debg build, if this is not done, no problems will be seen.  On a heavily loaded system, you will sooner or later run into problems, which quite likely will cause a segfault.  You were warned.

==See Also==
* [[r7.1.0:Misc|Misc]]