Messages in this thread | | | From | Nick Piggin <> | Subject | [rfc] SLOB memory ordering issue | Date | Thu, 16 Oct 2008 03:34:12 +1100 |
| |
I think I see a possible memory ordering problem with SLOB: In slab caches with constructors, the constructor is run before returning the object to caller, with no memory barrier afterwards.
Now there is nothing that indicates the _exact_ behaviour required here. Is it at all reasonable to expect ->ctor() to be visible to all CPUs and not just the allocating CPU?
SLAB and SLUB don't appear to have this problem. Of course, they have per-CPU fastpath queues, so _can_ have effectively exactly the same ordering issue if the object was brought back into the "initialized" state before being freed, rather than by ->ctor(). However in that case, it is at least kind of visible to the caller.
Anyone care or think it is a problem? Should we just document that ->ctor doesn't imply any barriers? Better ideas?
| |