[fdo-internals] FOR REVIEW: RFC 47 - Add Thread Support to FdoIDisposable AddRef/Release

[Jason Birch]

And maybe my question is partially invalid and based on an earlier
reading of the RFC :)

On 2010-01-15, Jason Birch <jason at jasonbirch.com> wrote:
> I was wondering why there isn't the option of using this in unmanaged
> code as well, maybe with some mechanism for choosing to use it or not?
>
> Does it make more sense or is it faster for the calling app in c++ to
> manage fdo's thread safety? If it's only faster, is there some way of
> implementing this RFC as the default, with a way for c++ apps to go
> bare-metal if they really need the performance?
>
> Feeling somewhat out of my depth :)
>
> Jason
>
> On 2010-01-15, Greg Boone <greg.boone at autodesk.com> wrote:
>> Hi All,
>>
>> I have written and posted FDO RFC 47: Add Thread Support to
>> FdoIDisposable
>> AddRef/Release, accessible at:
>>
>> http://trac.osgeo.org/fdo/wiki/FDORfc47
>>
>> Overview:
>>
>> 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 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.
>>
>> Regards,
>> Greg
>>
>