<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
h2
{mso-style-priority:9;
mso-style-link:"Heading 2 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:18.0pt;
font-family:"Times New Roman","serif";
font-weight:bold;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.Heading2Char
{mso-style-name:"Heading 2 Char";
mso-style-priority:9;
mso-style-link:"Heading 2";
font-family:"Times New Roman","serif";
font-weight:bold;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle25
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>This is correct if atomic_inc is
in a kernel header, that header should not be included from user-space.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>However, GCC does have other headers
defining atomic intrinsics, which can be included from user space.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>My point was about using mutex
vs. atomic, not specifically about which header (kernel or gcc) to include for
the atomic functions.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Traian<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Greg Boone<br>
<b>Sent:</b> Tuesday, January 19, 2010 12:46 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] FOR REVIEW: RFC 47 - Add Thread Support to
FdoIDisposable AddRef/Release<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span class=apple-style-span><span style='color:black'>When
exploring various posts on the usage of atomic_inc, I often see a warning not
to include kernel headers from userspace. There is even a pragma warning to
this effect in atomic.h.<o:p></o:p></span></span></p>
<p class=MsoNormal><span class=apple-style-span><span style='color:black'><o:p> </o:p></span></span></p>
<p class=MsoNormal><span class=apple-style-span><span style='color:black'>Are
you saying that it is safe to ignore this advice?<o:p></o:p></span></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Greg<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Traian
Stanev<br>
<b>Sent:</b> Friday, January 15, 2010 12:22 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] FOR REVIEW: RFC 47 - Add Thread Support to
FdoIDisposable AddRef/Release<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Theoretically both the GCC and
the MS VC++ implementations would be calling the same underlying Intel CPU dedicated
instruction that does the atomic operation. Chatter on the web is not always
reliable…, and I would personally doubt threading on Windows before I
doubt threading on Linux, given that Linux is used a lot more in thread-heavy
environments.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Traian<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Greg Boone<br>
<b>Sent:</b> Friday, January 15, 2010 12:17 PM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> RE: [fdo-internals] FOR REVIEW: RFC 47 - Add Thread Support to
FdoIDisposable AddRef/Release<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='color:#1F497D'>I took a look at functions such
as </span><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>atomic_dec_and_test</span><span
style='color:#1F497D'> and </span><span style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>atomic_inc_and_test</span><span style='color:#1F497D'>,
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. <o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Not being a 100% familiar with
these operations, I welcome any feedback on their use and the pros and cons of
doing so.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>NOTE: I do agree that
having a mutex per object is significant overhead on Linux.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Greg<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org
[mailto:fdo-internals-bounces@lists.osgeo.org] <b>On Behalf Of </b>Traian
Stanev<br>
<b>Sent:</b> Friday, January 15, 2010 12:12 PM<br>
<b>To:</b> 'FDO Internals Mail List'<br>
<b>Subject:</b> RE: [fdo-internals] FOR REVIEW: RFC 47 - Add Thread Support to
FdoIDisposable AddRef/Release<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Hi Greg,<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>What is the reason for using a
mutex on Linux instead of atomic operations like on Windows?<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'>Traian<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
fdo-internals-bounces@lists.osgeo.org [mailto:fdo-internals-bounces@lists.osgeo.org]
<b>On Behalf Of </b>Greg Boone<br>
<b>Sent:</b> Friday, January 15, 2010 11:53 AM<br>
<b>To:</b> FDO Internals Mail List<br>
<b>Subject:</b> [fdo-internals] FOR REVIEW: RFC 47 - Add Thread Support to
FdoIDisposable AddRef/Release<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Hi All,<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>I have written and posted FDO RFC 47: <b>Add</b> <b>Thread
Support to FdoIDisposable AddRef/Release</b>, accessible at:<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='text-indent:.5in'><a
href="http://trac.osgeo.org/fdo/wiki/FDORfc47">http://trac.osgeo.org/fdo/wiki/FDORfc47</a><o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><b>Overview:<o:p></o:p></b></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-left:.5in'><span style='color:black'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoNormal><b><span style='color:black;letter-spacing:-.2pt'>Proposed
Solution:<o:p></o:p></span></b></p>
<p class=MsoNormal><span style='color:black;letter-spacing:-.2pt'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='color:black'>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<o:p></o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='color:black'><o:p> </o:p></span></p>
<p class=MsoNormal style='margin-left:.5in'><span style='color:black'>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.<o:p></o:p></span></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Please refer to the RFC for a full description on the change
and a working draft of the proposed solution. <o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>All comments are welcome.<o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>Regards,<o:p></o:p></p>
<p class=MsoNormal>Greg<o:p></o:p></p>
</div>
</body>
</html>