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

[Traian Stanev]

Hi Jason,

Just to make it clear, making the refcount integer thread safe does not make any other member variables in any other FDO class thread safe. So there is no reason to turn this on apart from very specific cases where contention over the refcount causes objects to be deleted prematurely.

That said, it is possible to turn the locking on from unmanaged code -- in fact that's the only way to turn it on.

Traian

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Friday, January 15, 2010 2:07 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] FOR REVIEW: RFC 47 - Add Thread Support to FdoIDisposable AddRef/Release

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
>
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals