Lines Matching refs:in

6 hardware. This can mean many things in practice. For instance, moving from one
33 SPDK takes a different approach altogether. Instead of placing shared data in a
40 concurrency mechanism in [Go](https://tour.golang.org/concurrency/2). A message
41 in SPDK consists of a function pointer and a pointer to some context. Messages
47 in a cache closer to that core. It's often most efficient to have each core work
48 on a small set of data sitting in its local cache and then hand off a small
56 employed in the I/O path. This of course trades memory size for computational
57 efficiency, so it is used in only the most critical code paths.
62 fundamental libraries in SPDK, for instance, don't do any message passing on
63 their own and instead enumerate rules about when functions may be called in
66 abstraction, located in `libspdk_thread.a`. The thread abstraction provides a
77 threading in SPDK.
87 pattern emerging in a number of different libraries. In order to implement a
90 in the I/O path to avoid locking on the global state. The pattern was clearest
91 in the lowest layers where I/O was being submitted to block devices. These
95 Over time, however, the pattern has appeared in a huge number of places that
115 There are some cases where locks are used. These should be limited in favor of
121 is safe to use in SPDK libraries and applications. This safety comes from
128 framework for all of the example applications it shipped with, in the interest
130 of course require something that implements an asynchronous event loop in order
131 to run, so enter the `event` framework located in `lib/event`. This framework
139 Message passing is efficient, but it results in asynchronous code.
140 Unfortunately, asynchronous code is a challenge in C. It's often implemented by
175 them in C we can still write them out by hand. As an example, here's a
265 from top to bottom to get a clear overview of what's happening in the code