[M3devel] per thread data?

[Jay]

I'm not looking at it right now, but doesn't seem rather piggy to have two thread locals and data on the side?

 

 

I'm guessing the data on the side is needed because we need to be able to enumerate our threads, to suspend them all?

 

 

I understand that having multiple thread locals optimizes their use, but it seems greedy.

vs. a small heap allocation that combines them.

 

Or in fact.. presumably there could just be one thread local that is the thread pointer, and the handler link could be put at the start, for architectures where zero offset is smaller/faster than non-zero offset.

 

 

Another idea, of course, is to look into "__thread", "__declspec(thread)".

 

On Windows and probably all platforms they exist on, they are nicely more efficient than pthread_get/setspecific, except on Windows they don't really work acceptably prior to Vista -- they only work in .exes and their static dependencies, not any .dll you load after the process starts with LoadLibrary (dlopen).

 

 

Does "__thread" work well on most non-Windows platforms?

i.e. even if shared object is loaded with dlopen?

 

 

I could have sworn I saw code out there that was "adaptive".

It easily/efficiently checked if it was loaded with LoadLibrary or not.

If so, it'd TlsGet/SetValue (pthread_get/setspecific).

If not, it'd use __declspec(thread) (__thread).

The check was based on if __tlsindex was not zero or somesuch. I couldn't track it down though.

 

 

In either case, yes, I know, one of the thread locals at least is gone on platforms that have stack walkers, e.g. Solaris, and potentially NT, and maybe others.

 

 

 - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090318/e3354aed/attachment-0001.html>