Make circular buffer thread-safe

[wallento]

I think making the circular buffer thread-safe is a first step towards #8

[imphil]

cbuf already has single reader/writer semantics, as expected from a FIFO (see http://www.glip.io/group__development-cbuf.html). What kind of thread-safety are you looking for?

[wallento]

multiple producer, single consumer for outgoing and single producer, multiple consumer for outgoing. I think the userspace should be allowed to be multithreaded.

[imphil]

What's the specific use case for that? And how common is it to justify putting the locking overhead into the library itself, as opposed to letting the user of the library add locking if necessary?

[wallento]

It should be used to a NBDS then anyways. We are already locking at each access, so even moving the lock a bit does not harm for the moment. Overall nothing urgent, but thread-safety is important.

[wallento]

Use case: Generating data from multiple threads

[imphil]

From all cases I can think of and have implemented, the application that uses GLIP is implementing a higher-level protocol on top of the FIFO semantics provided by GLIP. Almost all protocols rely on specific data ordering. To provide this data ordering, a sequential write or read is necessary.

If the data is written or read ordered, already an implicit locking is present in the user's code and there's no need for concurrent access to the read or write functions.

Therefore, could you please sketch a specific use case where we
a) have a protocol which does not require sequential reading/writing of data
b) gain performance or other benefits by doing the required locking inside GLIP.

Independent of that, as you mentioned, the implementation of the cbuf read/write functions could be improved to be non-blocking. Doing this is, however, independent of the question what thread safety guarantees cbuf should provide.

[wallento]

Regarding your question, full thread-safety is the best and favorable property on the glip API in general