Responding to your original note because I had some more fundamental questions about what
On Tue, 2018-07-31 at 12:31 +0300, Andrey Kuzmin wrote:
Working on a vbdev that maintains some global state and underlying data structures, I
explore an SPDKish alternative to the traditional synchronization, that of the
semantics where global data structures are being maintained by a dedicated thread, with
being served by message passing to/from that thread.
Coding such a thread against the spdk_allocate_thread() guidelines proved to be quite
straightforward, and I've got it up and running. At the same time, I'm still
unclear as to why I
should be essentially duplicating the features of the pinned SPDK thread, with my gut
being that the very same single-threaded semantics could have been easily achieved by
execution context to some randomly or round-robin chose pinned thread of the configured
I'm not sure I follow entirely, but it sounds like you spawned your own (POSIX) thread
registered it using spdk_allocate_thread(). That's valid, but almost none of the SPDK
that. Instead, it typically assigns data to an existing thread (one of the ones pinned to
and uses spdk_thread_send_msg() to pass messages to that thread to manipulate the data.
If that gut feeling doesn't fool me, I will appreciate a pointer
to any docs and/or examples
showing how one can pin an arbitrary execution context inside a vbdev to an SPDK native
(similar to app_start and friends, I believe), and do polling on that thread/ messaging
that thread similar to what a POSIX thread equipped with spdk thread envelope could do.
Elsewhere you responded to Jim that you are using an spdk_mempool to pool objects used for
process communication and that sounded some alarm bells for me. I think if you assign your
one of the existing SPDK threads and use spdk_thread_send_msg(), you don't need to do
any of that.
The message passing scheme is all already done for you. If you need to periodically
execute code on
one of the existing threads, you can register a poller by calling spdk_poller_register().
iterate over all of the threads using spdk_for_each_thread().
A strategy SPDK commonly employs is that the first thread to access some data
"owns" it, and all
subsequent accesses are done via message passing. You may want to try that for your use
As far as documentation, there is always this: http://www.spdk.io/doc/concurrency.html
There is active work going on in this area too. I put out this patch recently:
That's for discussion purposes only and it doesn't currently meet all the needs of
intended for, but it should give some insight into the general direction the project is