From: John Brett (John.BrettQUOVADX.COM)
Date: Tue Mar 18 2003 - 02:42:54 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

<snip>

> The InterlockedXXXX functions guarantee that the variable will not be
> updated simutaneously by more than one thread and the return
> value is the
> resulting updated value (NT 4.0 or later) but consider this scenario
>
> 1. m_dwRef is at 0

This is an unlikely starting point. Typically, the object
is created with a reference count of 1 (the reference returned
to the creator). Thereafter, m_dwRef will stay positive until
the object is destroyed.

> 2. Thread A enters AddRef and calls InterlockedIncrement(&m_dwRef)
> 3. Thread A returns from InterlockedIncrement and now m_dwRef is 1
> 4. Thread B enters Release and calls InterlockedDecrement(&m_dwRef)

How would thread B get hold of a reference to the object
in the first place? The point about reference counting is
that it counts the number of references to the object, so
if thread B has a reference to the object, as well as thread
A, then m_dwRef should be at least 2.

> 5. Thread B returns from InterlockedDecrement and now m_dwRef is 0
> 6. Thread A returns from AddRef() and continues executing
> using the COM ptr
> 7. Thread B sees that ref count now is 0 and call delete this
> 8. Thread A crashes
>
>
> Is it possible ????

Shouldn't be. However, COM is notorious for reference counting
bugs. Especially when you don't use the wrappers and templates :-)

John

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]