<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: A .NET code sample: Real-time data streaming and control.</title>
	<atom:link href="http://rdn-consulting.com/blog/2007/09/24/a-net-code-sample-real-time-data-streaming-and-control/feed/" rel="self" type="application/rss+xml" />
	<link>http://rdn-consulting.com/blog/2007/09/24/a-net-code-sample-real-time-data-streaming-and-control/</link>
	<description>Software Development and Biomedical Engineering</description>
	<pubDate>Thu, 20 Nov 2008 13:26:26 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Andrew Dallas</title>
		<link>http://rdn-consulting.com/blog/2007/09/24/a-net-code-sample-real-time-data-streaming-and-control/#comment-151</link>
		<dc:creator>Andrew Dallas</dc:creator>
		<pubDate>Fri, 28 Sep 2007 14:41:58 +0000</pubDate>
		<guid isPermaLink="false">http://rdn-consulting.com/blog/2007/09/24/a-net-code-sample-real-time-data-streaming-and-control/#comment-151</guid>
		<description>As my company, Full Spectrum Software, focuses on medical and scientific software, we've had the opportunity to build scads of data acquisition systems including neurodiagnostic, and other high-speed medical applications. There are a few critical aspects to doing this right and fortunately we've been at this a long time.
What we've found is that reducing friction within the system is absolutely critical. Friction points occur when threads compete for a common resource. The programming technique used to ensure data integrity is maintained is mutexing, a method of blocking access to a particular resource such as a FIFO buffer. This mutexing can cause contention between threads and therefore reduce data throughput. So you must mutex but do so for the shortest duration you can and only mutex when you must. There are several algorithms that work effectively here.
Another point of friction is calling through to unmanaged code from managed code. While the unmanaged code may be somewhat better performing, the marshalling and mode switch are often major performance hits. So use unmanaged if you must but weigh the cost first if you don't and are working under the assumption that the performance will improve your system’s throughput.</description>
		<content:encoded><![CDATA[<p>As my company, Full Spectrum Software, focuses on medical and scientific software, we&#8217;ve had the opportunity to build scads of data acquisition systems including neurodiagnostic, and other high-speed medical applications. There are a few critical aspects to doing this right and fortunately we&#8217;ve been at this a long time.<br />
What we&#8217;ve found is that reducing friction within the system is absolutely critical. Friction points occur when threads compete for a common resource. The programming technique used to ensure data integrity is maintained is mutexing, a method of blocking access to a particular resource such as a FIFO buffer. This mutexing can cause contention between threads and therefore reduce data throughput. So you must mutex but do so for the shortest duration you can and only mutex when you must. There are several algorithms that work effectively here.<br />
Another point of friction is calling through to unmanaged code from managed code. While the unmanaged code may be somewhat better performing, the marshalling and mode switch are often major performance hits. So use unmanaged if you must but weigh the cost first if you don&#8217;t and are working under the assumption that the performance will improve your system’s throughput.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
