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
