[M3devel] thread local storage, but in C pieces of runtime... (jay, tony?)

[Jay K]

It is in C for portability. Like everything else.  Otherwise you have to duplicate the C headers in Modula-3, and they end up being system specific because there are too many ways to turn the portable C source interface into non-portable ABI -- #defines, #pragmas, etc.  For Linux I do at least use __thread instead of pthread_getspecific.I found __thread support too varying/missing to use otherwise.  http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/thread/PTHREAD/ThreadPThreadC.c?rev=1.169;content-type=text%2Fplain  Look for "M3_COMPILER_THREAD_LOCAL"  Oh, only for the builtin thread local "activation".  There is no mechanism within the Modula-3 language or libraries to use thread locals.To do this efficiently as you'd like, you need to extend the M3CG interface and the existing backends.Or you can do it strictly through libraries.  Or you can avoid thread locals. They are almost as bad as globals.They don't make for reentrant code, only thread safe code.Consider a nested for loop using strtok, for example.   > no kernel space is involved in accessing  That is probably true of all implementations.Apple's is said to be fast, to that is implied.NT doesn't involve the kernel and is reasonably fast (disassemble kernel32!TlsGetValue).Allocation maybe, but not access.   > Also, on Linux since 2004, uncontested lock is user-space only  Linux is not alone here or necessarily better than any system.Win32 critical sections have always been user-mode only if uncontended.Modula-3 locks I believe are too.  I wouldn't be surprised if every system or every current system is the same in this regard.Everyone knows that kernel calls are expensive and to be minimized.   > Linux pioneered lightweight processes/threads in free *nix world, and others followed  Long after probably every commercial system got it right, e.g. at least Solaris and NT, probably everything else too.   - Jay
From: dragisha at m3w.org
Date: Fri, 10 May 2013 18:39:33 +0200
To: mika at async.caltech.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] thread local storage,	but in C pieces of runtime... (jay, tony?)

AFAIK, Linux ABI uses dedicated register (one of segment registers) to access TLS. It's setting is part of context switch, and one is only supposed to use it read-only. No kernel space is involved in accessing, and was not since NPTL was introduced.

Old and FreeBSD does ring bells :). Linux pioneered lightweight processes/threads in free *nix world, and others followed. If your test was near enough in time to 2004-5-6, then probably it was a time when FreeBSD played catch-up.
Also, on Linux since 2004, uncontested lock is user-space only. It probably involves a barrier of some kind, but it is under 0.5microsecond in worst case, as opposed to 20-50microsecond for kernel space operation.
So, it is efficient :).

On May 10, 2013, at 5:22 PM, mika at async.caltech.edu wrote:This is just one data point, but I remember testing the performance of thread locals
on pthreads, probably on an old FreeBSD system, and the performance was horrendously
bad.  There was a system call involved in obtaining the pointer to the thread-local
area.  I was had some clever algorithms I wanted to use thread locals for (since you
can do all sorts of things without locks then), but I gave up on it since it was way
more expensive than a lock on that system...

    Mika
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130510/95ccca41/attachment-0002.html>