Re: [boost] Re: [Formal review] Singleton library

From: Bjørn Roald (bjorn_at_[hidden])
Date: 2005-05-09 01:33:08

David Abrahams vrote:

> Bjørn Roald <bjorn_at_[hidden]> writes:
>
>> Pavel Vozenilek wrote:
>>
>>> A library named Shmem is being developed
>>> (quite mature, can be found in sandbox).
>>>
>>> With this or similar library one could allocate small, uniquely named
>>> memory block and singleton infrastructures from each DLLs would
>>> (behind the curtain) use it.
>>>
>>> Then there would be no need for separate Win32 interface.
>>
>> I agree that shared memory is one way to solve this.  Note however that 
>> this
>> is a problem that is specific to DLLs on windows -- where the meaning of 
>> C++
>> writeable static variables is broken.  This is AFAIK not an issue with 
>> any
>> other dynamic libraries like .so files in unix/linux.  It is important to
>> limit the workaround to the windows environment.
>
> If you are referring to the fact that static variables with the same
> name can be allocated in multiple DLLs, so that you see different
> values from each DLL, your information is incorrect and I disagree
> with your characterization of it as "broken".  GCC now supports
> restricting symbol visibility for ELF platforms.  See
>
>  http://www.nedprod.com/programs/gccvisibility.html
>
> As I see it, this model (essentially the Windows model) is actually
> much less broken than the usual one on Unix where everything forms a
> big "symbol soup."
>

You left out the portion of my post where I mentioned that Windows DLLs have 
benefits, I certainly agree that their ability to provide much better 
encapsulation than other models is great.  That is not what I think is 
broken. Your information about GCC was new to me and interresting, I will 
study it in detail when I get more time.  Thanks :)

The problem I refer to, which I think is the relevant problem for this 
thread is that static variables are instanciated by the DLL loader or 
whatever, in a manner where there becomes more than one instance of the same 
static variable in the same process.  This is not consistent with my 
understanding of the C++ language.  If these static variables are constants 
or initialized consistently and treated as constants, this never becomes a 
real problem.  I however they are writable and are writen to you end up with 
with more than one value for the same static variable in the same program. 
In my view this is broken.

It has been some years since I did heavy work with Windows, the tools I used 
was MSVC++ 5.0 + Dincumware's sepearate standard library (not the one 
bunndled by MS in those days).  Dinkumware provided standard libraries that 
fixed these issues and others providing DLL compliance,  something MS never 
informed their customers that the bundeled versions where not designed to 
do.  If I remember right, the static writable issue was the hardest nut to 
crack even for Dinkumware gurus.  I think this should be fixed since it 
makes programming more dificult than needed.  I know there may be a 
defendable position taken to argue that this is not broken, since the C++ 
standard does not say much about what a program is.  In addition MS defines 
something they call context (if I remember right).  You can explicitly 
switch between the context of one DLL to the context of another, thus 
controlling which static variable instance you are working on.  So a DLL 
based program probably only have only one instance of a static variable per 
context.  This may AFAIK be suficient to claim C++ compliancy.  But I 
considder this to be something almost none of the C++ developers I have ever 
met is aware of.  So if it holds water, I am not realy interested -- I still 
cosidder it broken.

For the singelton library, it may be possible to always switch context to 
the DLL owning the singelton before the static variable is accessed.  I have 
not had time to study the libray code yet, so I do not know how hard this 
may be to get right.  If this is done properly, use of shared memory may not 
be needed.

----
regards
Bjørn Roald