[fdo-internals] FOR REVIEW: RFC 47 - Add Thread Support to
greg.boone at autodesk.com
Fri Jan 15 12:17:23 EST 2010
I took a look at functions such as atomic_dec_and_test and atomic_inc_and_test, but there was a lot of chatter on the web that these calls were not sufficient to provide full thread synchronization. In that light I chose to adopt the strategy MapGuide used and implement the solution on Linux using a mutex.
Not being a 100% familiar with these operations, I welcome any feedback on their use and the pros and cons of doing so.
NOTE: I do agree that having a mutex per object is significant overhead on Linux.
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Friday, January 15, 2010 12:12 PM
To: 'FDO Internals Mail List'
Subject: RE: [fdo-internals] FOR REVIEW: RFC 47 - Add Thread Support to FdoIDisposable AddRef/Release
What is the reason for using a mutex on Linux instead of atomic operations like on Windows?
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, January 15, 2010 11:53 AM
To: FDO Internals Mail List
Subject: [fdo-internals] FOR REVIEW: RFC 47 - Add Thread Support to FdoIDisposable AddRef/Release
I have written and posted FDO RFC 47: Add Thread Support to FdoIDisposable AddRef/Release, accessible at:
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.
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
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.
Please refer to the RFC for a full description on the change and a working draft of the proposed solution.
All comments are welcome.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fdo-internals