Hi Chris, Thanks a lot, you explanation solves my concerns clearly.
2017-05-23 21:47 GMT+08:00 Luke, Chris <chris_l...@comcast.com>: > It is not thread safe; it’s up to the caller to be thread safe. Typically > each thread works on its own memory and objects to avoid cross-thread > locking or cross-socket cache invalidation. > > > > Most volatile objects are typically modified by the API or CLI and there’s > a main thread that hosts these entry points and In effect this serializes > accesses so that locking/synchronization is much less necessary. > > > > Where it’s absolutely necessary we use spinlocks to synchronize such > things but try *really* hard not to. > > > > Chris. > > > > *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On > Behalf Of *??? > *Sent:* Monday, May 22, 2017 22:38 > *To:* vpp-dev@lists.fd.io > *Subject:* [vpp-dev] Question regarding pool_get/pool_put thread safety > > > > Hi folks, > > > > There is a pool_get and pool_put macro based on vec structure, quite a few > code rely on that, however, I have a question regarding about the thread > safety of these two APIs, I do not found any comments for them. > > > > Since pool_get may resize the vec, is there any issue if another worker > thread trying to use pool_put which may refer to the old underlying vec? > > > > Or there is some implicit coding convention to use the two APIs? > > > > Thanks a lot. > > > > >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
