Changes between Version 9 and Version 10 of FDORfc47

Timestamp:

Jan 15, 2010, 8:36:26 AM (14 years ago)

Author:

gregboone

Comment:

--

FDORfc47

@@ -23 +23 @@
 == Overview ==
 
-The !AddRef / Release / !GetRefCount methods on FdoIDisposable are not currently thread-safe.  As a consequence the m_refCount data member can get corrupted if two separate threads simultaneously call any of these methods on the same object.  This is known to happen during garbage collection of Managed FDO objects.  Because the managed objects implement a finalizer, they are processed by a separate GC finalizer thread.  So while the GC finalizer thread is releasing ref counts on unmanaged objects, the main thread can be simultaneously modifying ref-counts on those same objects.
+The !AddRef and Release methods on FdoIDisposable are not currently thread-safe.  As a consequence the m_refCount data member can get corrupted if two separate threads simultaneously call any of these methods on the same object.  This is known to happen during garbage collection of Managed FDO objects.  Because the managed objects implement a finalizer, they are processed by a separate GC finalizer thread.  So while the GC finalizer thread is releasing ref counts on unmanaged objects, the main thread can be simultaneously modifying ref-counts on those same objects.
 
 == Proposed Solution ==
 
-In !MapGuide this issue is addressed by having all the unmanaged API classes extend from !MgGuardDisposable, which uses a mutex to limit access to the ref-count member to one thread at a time.  
+In !MapGuide the refcount threading issue is addressed by having the refcounted classes extend from !MgGuardDisposable, which in turn uses a mutex to limit access to the refcount member variable to one thread at a time. A similar solution will be implemented for the FDO API, with a slight variation. On Linux, a mutex will be used. On Windows, the FDO API will use the !InterlockedIncrement and !InterlockedDecrement methods. 
 
-A similar solution will be implemented for the FDO API, with a slight variation. The FDO API will use !InterlockedIncrement and !InterlockedDecrement as opposed to a mutex. Also, the use of these thread safe functions will be limited to FDO objects that are wrapped by a Managed object wrapper.
+On Windows, the use of thread safe functions will always be activated in case where unmanaged FDO objects are wrapped by a Managed object wrapper. Otherwise, API callers will have the option of setting a per-object or global flag that will activate thread-safe access of the reference count member variable. 
 
 Here are the detailed steps that will need to be taken to implement the solution:
 
-    * Add a flag to FdoIDisposable (Boolean member variable) to indicate if Interlocked support should be enabled for FDO disposable objects
-    * Add a virtual method on FdoIDispoable that will indicate if Interlocked access should be enabled. E.g. bool !EnableInterlocked()
-    * Add Interlocked calls to !AddRef and Release that will only be executed if the boolean flag set by !EnableInterlocked() is True.
-    * Change the Managed FDO API's MgFdoIDisposable class to call !EnableInterlocked whenever creating an FDO managed wrapper object around an FDO unmanaged object.
+    * Add a static flag to FdoIDisposable (Boolean) to indicate if thread locking support should be enabled for all disposable objects
+    * Add a local flag to FdoIDisposable (Boolean) to indicate if thread locking support should be enabled for this disposable objects
+    * Add a virtual method on FdoIDispoable that will allow callers to enable thread locking for this object. 
+    * Add a static method on FdoIDispoable that will allow callers to enable thread locking for all disposable objects. 
+    * Add thread locking calls to the implementation !AddRef and Release that will only be executed if one of the boolean flags defined above is True.
+    * Change the Managed FDO API's MgFdoIDisposable class to enable thread locking whenever creating an FDO managed wrapper object around an FDO unmanaged object.
 
 This solution should provide thread safe access for clients using the FDO Managed API while allowing those who use the unmanaged FDO API directly to avoid the added overhead of Interlocked support.