From: Donal K. F. <don...@ma...> - 2012-11-22 11:56:32
|
On 21/11/2012 18:11, Andreas Kupries wrote: > - Can we make Tcl_Obj* allocation fast without tying the Tcl_Obj* to > a thread? I'm guessing not. The space from which pieces of memory are allocated is a shared resource, and one that *must* be kept consistent or all heck breaks loose. Splitting it up by thread is a big gain for a very large proportion of programs. It's also *very* hot; Tcl stresses memory management far more than most programs. Let's be clear about this: Tcl's model solves far more problems than it creates. Our allocators are much faster than those used in, say, C++ in the normal case. (The C++ response is to use the stack for much more memory management, but that has its own set of problems...) > - Can we modify Tcl_Obj* structures to deal with a Tcl_Obj* which is > used from a non-owning thread? > - Related, not quite the same, can we modify Tcl_Obj* to deal if > elements reside in different threads ? (list/dict obj vs list/dict > elements?) Detection isn't difficult; it requires one extra field. The problem is what to do after that as the object's contents can shimmer away at any time. You can't really change anything safely (solutions proposed with 'volatile' tend to run into trouble with real hardware, as there's no reason to believe that the other thread accessing the Tcl_Obj will be on the same CPU die; you need memory barriers to force a flush out to the main bus and that really hurts). Duplicating on transfer is far easier, since we can persuade the sender to not change anything during the transfer period, allowing for a lock-free copy to be done by the receiver. > - And if the last one is possible, could the deep copy be done in a > lazy fashion, i.e. only when a thread X has to deal with a Tcl_Obj* > owned by Y ? But how to persude Y not to change it while X is looking at it? At the level we're dealing with, there's no way to be sure that won't happen without locking (either using low-level locking or via higher level protocol guarantees in the messaging layer). My instinct is to add an operation to the Tcl_ObjType to do the "deep duplicate" and which will be called to copy the object when it enters the target thread while the source thread guarantees to not modify it. User code won't need to implement the method, in which case we'll default to doing a string copy, but some types will be able to be much more efficient (notably numeric types, lists and dicts). What I want to know is whether we can get this down to something as simple as Tcl_DuplicateObj() in the source (if necessary) and (the totally new, all invented on the spot) Tcl_DeepCloneObj() in the target. That would be interesting to try as it would at least be easy to implement correctly if it works as a protocol at all... Donal. |