From: Andreas K. <and...@ac...> - 2012-11-21 18:17:59
|
On Wed, Nov 21, 2012 at 6:57 AM, Donal K. Fellows <don...@ma...> wrote: > On 21/11/2012 14:44, Larry McVoy wrote: >> >> I'd suggest that a focus on making use of multiple processors would get >> you a much bigger win with far less effort. > If I was to work on improving threading, I'd be just looking at how to make > inter-thread messaging cheaper. It's got to be possible to avoid dragging > *everything* through strings... One possible solution is to extend Tcl_ObjType with a function to perform deep-copy of intreps. I.e. dup a Tcl_Obj* into a new one, with all the structure underneath. This operation must allow use of a Tcl_Obj* owned by thread A from within the thread X doing the copy. Or, in reverse, have thread X make a dup and have it owned by Y. That might be more feasible, if we can find a way of talking to the obj allocator of a different thread without having to resort to mutex by any thread for their own allocator. The main issue underneath this is that Tcl_Obj* are __owned__ by the thread allocating them. This is the only thread which can free them also, or is (currently) allowed to access them. Thus we cannot simply pass the Tcl_Obj* to a different thread. Accessing and messing up data structures belonging to the owning thread is a no-no. The simple solution was to generate the string rep, because that can be passed as simple pointer. From there the destination thread reconstructs the intrep. In the proposed solution above the time taken by reconstruction of the intrep will go to making a deep copy. The space requirements of both should be the same., actually better for deep copy, as it can account for sharing, where the string rep is fully expanded. Why do we have Tcl_Obj* owned by particular threads ? AFAIK, IIRC this is an effect of us using thread-local memory pools for Tcl_Obj* (de)allocation. Which makes the majority of allocations fast. Only if the local pool is exhausted will we have to go to the global pool and through mutex synchronization. (Which is used to extend the local pool, actually). So, other potential solutions would have to look into - Can we make Tcl_Obj* allocation fast without tying the Tcl_Obj* to a thread? - 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?) - 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 ? -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ P: 778.786.1122 F: 778.786.1133 and...@ac... http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato Tcl'2013, Sep 23-27, New Orleans, LA, USA. |