RFC 16: MapScript WxS Services

[Tamas Szekeres]

>
> To the best of my knowledge, the various TLS API's internally use a mutex
> to manage access to a list of thread local datastructures much as I do.
> The benefit of a TLS API is that it is likely implemented better by the
> operating system folks, and it is abstracted from us.

Frank,

In the Win32 implementation
TLSAlloc may need a synchronization since it reserves the index for
exclusive use from the other entities of the process. However it may
occur once per index at the beginning and after the index could be
read simultaneously by the multiple threads from a global variable.
(There's no need to do syncronization with it). The per thread TLS
slots can be accessed by TLSSetValue and TLSGetValue which are thread
neutral and does not require implicit thread synchronization. Theese
slots are allocated at the thread's stack space, however it depends on
the implementation (according to
http://support.microsoft.com/kb/94804/EN-US)


>But really, many
> OS services already use mutexes within them to work properly in
> multi-threaded environments, including every malloc/free, and printf call
> when using thread-safe C libraries.
>

It might be true. I'm not sure about malloc and free.


I think we could implement similar - but not equivalent -
functionality by preallocating a global table containing the the
assignments between the thread id-s and the io contexts. We would only
need to make synchronization if a new thread id comes in, and a new
assignment should be created. The lookup of this table could be done
without locking. We should only consider the multple access of the
number of elements in the table. Simple reads and writes to
properly-aligned 32-bit variables are atomic. That is, when one thread
is updating a 32-bit variable, you will not end up with only one
portion of the variable updated; all 32 bits are updated in an atomic
fashion.


Best Regards,

Tamas Szekeres