On Thu, 2007-11-01 at 21:02 -0700, Gary Funck wrote: > On Thu, Oct 18, 2007 at 11:42:52AM +1000, skaller wrote: > > > > DO you know how thread local variables are handled? > > [Not using Posix TLS I hope .. that would be a disaster] > > Would you please elaborate?
Sure .. > What's wrong with the POSIX TLS implementation? I have no idea, the implementation is irrelevant: the interface is likely orders of magnitude slower than the proper way to do thread local storage: use the stack. Posix TLS is a hack. New code should NOT use TLS, it is only for supporting broken legacy code. For example in the C library the global errno variable. This is a DESIGN FAULT in ISO C89 which can be 'repaired' by using TLS, but one should never design such a bad interface in new code. A really cool (non-Posix) implementation would put TLS globals on the stack base .. but this does require at least one extra machine register in languages like C which don't provide a static display (pointer to parent function). For languages that do, such as Modula and most FPLs, the display pointer has to be provided anyhow, so the TLS globals come at no extra cost. > Do you know of any studies? No, but I would guess gcc has some performance regression tests? > I ask, because we presently use the TLS facility extensively, > and have suspected that there are significant performance > problems, but haven't looked into the issue. There are bound to be performance issues if you have to query any kind of global data base shared between threads to obtain data local to the thread. The only exception to this is the data held in the 'task state', which is typically just the machine registers and in particular the stack. If this data is on or reachable from the machine stack in the first place, there's no performance problem and no need for TLS. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
