Subj : Re: Can C++ local static objects be made thread safe?
To   : comp.programming.threads
From : Olivier Huet
Date : Thu Jan 20 2005 12:00 am

Hello,


Marcin 'Qrczak' Kowalczyk a écrit :
> Olivier Huet <huet-pasdespamsvp-.o@caramail.com> writes:
> 
> 
>>>Depending on whether the variable is process wide or system wide.
>>
>>Yes, but generally, the compiler itself doesn't know it : in a lot of
>>couples compiler+OS, variables are done "system wide" with some OS
>>calls : shared memory, memory file mapping etc.
> 
> 
> On Unix a static variable in a function cannot be system wide. You can
> obtain shared memory or mmap region first, and then put objects at the
> address you got. This can't apply to static variables whose address is
> predetermined by the compiler.
> 

Yes. And if I remember well, it's precisely like you say in Linux. But 
there are a lot of unices and a lot of compilers in thoses OS : perhaps 
on some couple of them, we can map "system wide", (or "user wide" ?) 
variables automatically.

> I think on Windows you can choose whether a DLL will have its memory
> shared between processes or not. Determining the kind of lock should
> be delayed until the scope of the DLL is determined. I don't know if
> this is implementable.
> 

Yes, it is possible to generate a "shared" sections in a Windows dll, 
and put global variables on the section. I'm not sure it is really 
possible with local static variable (I will check it later).

To resume, shared section are "flagged" like this by the compiler + linker
- compiler : you place a variable in a section with a #pragma
- linker : you put a flag on the section
After, this is only OS stuff.

-> So as it is now, you can't really say "this variable is shared" to 
the compiler : it can't know it. Only the OS can uses this flag of the 
section, and share it.


So to resume my idea, C and C++ are generally used to do some low level 
stuff with OSes. So I think that an "automatic" and perhabs "bad choosed 
by the compiler" locking mecanism can limit this low level OS dialog 
generally appreciated by C and C++ developpers.

But as I said previously, I would appreciate a an extension, to do some 
automatic locking : I only think that it should not be turned on by default.


Olivier Huet

.