Why is function static singleton not thread-safe? 
Author Message
 Why is function static singleton not thread-safe?

The  method espoused by Scott Meyers and others for having a single instance
of a class includes the following ideas:

class CMyClass
{
    CMyClass(){}
public:
    static CMyClass& MyClass();

Quote:
}

static CMyClass& CMyClass::MyClass()
{
    static CMyClass myclass;
    return myclass;

Quote:
}

I've read in several places that this approach is not thread-safe, but I'm
not sure why.  Is it because the machine code that checks for existance and
allocates a CMyClass instance is not thread-safe?  In other words, is it
because of this scenario:
1.thread A enters the function, sees that myclass doesn't exist yet, loses
the CPU
2.thread B enters the function, sees that myclass doesn't exist yet, loses
the CPU
3.thread A regains the CPU and creates another myclass
i.e. pseudoobjectcode:
jump to MyClass()
if myclass doesn't exist
{
    create myclass

Quote:
}

If this is correct but there are any other reasons why this is not
thread-safe, please explain.


Mon, 18 Jul 2005 05:35:38 GMT  
 Why is function static singleton not thread-safe?

Quote:
> I've read in several places that this approach is not thread-safe, but
I'm
> not sure why.  Is it because the machine code that checks for
existance and
> allocates a CMyClass instance is not thread-safe?  In other words, is
it
> because of this scenario:
> 1.thread A enters the function, sees that myclass doesn't exist yet,
loses
> the CPU
> 2.thread B enters the function, sees that myclass doesn't exist yet,
loses
> the CPU
> 3.thread A regains the CPU and creates another myclass
> i.e. pseudoobjectcode:
> jump to MyClass()
> if myclass doesn't exist
> {
>     create myclass
> }

Precisely so.

-cd



Mon, 18 Jul 2005 05:37:11 GMT  
 Why is function static singleton not thread-safe?
I guess Carl knew what I meant, but just to clarify for anyone else that may
read this in the future,
step 2. should have said:
2.thread B enters the function, sees that myclass doesn't exist yet,
allocates an instance of CMyClass, loses the CPU


Quote:
> The  method espoused by Scott Meyers and others for having a single
instance
> of a class includes the following ideas:

> class CMyClass
> {
>     CMyClass(){}
> public:
>     static CMyClass& MyClass();
> }

> static CMyClass& CMyClass::MyClass()
> {
>     static CMyClass myclass;
>     return myclass;
> }

> I've read in several places that this approach is not thread-safe, but I'm
> not sure why.  Is it because the machine code that checks for existance
and
> allocates a CMyClass instance is not thread-safe?  In other words, is it
> because of this scenario:
> 1.thread A enters the function, sees that myclass doesn't exist yet, loses
> the CPU
> 2.thread B enters the function, sees that myclass doesn't exist yet, loses
> the CPU
> 3.thread A regains the CPU and creates another myclass
> i.e. pseudoobjectcode:
> jump to MyClass()
> if myclass doesn't exist
> {
>     create myclass
> }

> If this is correct but there are any other reasons why this is not
> thread-safe, please explain.



Mon, 18 Jul 2005 22:36:43 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Call to local static object constructor not thread-safe

2. Why OleDbCommand objects are not thread safe?

3. thread-safe singleton?

4. Thread functions are thread-safe?

5. Why I am getting Error C2091: function returns function

6. Thread Safe Events and Static Methods

7. Are static methods thread safe?

8. Singleton not a singleton?

9. Is static variable initialization thread-safe?

10. How to make static methods thread safe

11. Why isn't ICollectionOnSTLImpl thread-safe?

12. Why am I not getting correct position?

 

 
Powered by phpBB® Forum Software