Saturday, April 14, 2018

Locking Resources in C# for Read/Write Concurrency

In a previous project, I became a big fan of System.Threading.ReaderWriterLockSlim.  It was an excellent way to guard a resource against concurrency in a relatively flexible manner.  

C# has a lock(object) {} syntax for simple concurrency locks, but what if you have a resource that can sometimes be used concurrently, and other times, exclusively?

Enter System.Threading.ReaderWriterLockSlim.  This has a few handy methods on it for guarding code on a non-exclusive (Read) and exclusive (Write) mode, with an upgradeable lock, as well, so you don't have to release a read lock in order to upgrade it.

This source works just as well in .NET as UWP.

I commented the code enough to try to make it so that someone familiar with ReaderWriterLockSlim and using(IDisposable){} would understand the rest, so without further ado...

Friday, December 22, 2017

Unloading the UI Thread in C# on Windows 10 + UWP

First I want to thank Matthew Groves for hosting the 1st known C# Advent (English).  I was honored to be able to grab the spot for Friday, December 22, 2017, which, happily, is the start of my Christmas holiday week, as well.

The crux of this post is that most visible performance issues in a Windows application come from the presentation layer.  Specifically, anything that puts load or wait states on the main "UI Thread" will make the app/application appear to hang or become unresponsive for periods of time. This post talks about strategies for getting load off the UI as much as possible, beyond the async/await mechanism in C#.  Most such load can be unloaded to a worker thread fairly easily.  Other tasks can be awaited together. In some cases, a UI component is involved, and it becomes necessary to manage load that, for that reason, reason MUST stay on the UI thread.

I remember when I was a kid hearing of projects for stock traders that handled hundreds of data update events every second and being totally intimidated by the thought of it.  I knew I'd "come of age" in technology when, in 2017, I worked with a focused team (known as "Blockheads") to build such an app.  This latest generation "stock blotter" ran stable, without memory leakage, and with no apparent lag at tens of Gigabytes per second! These general ideas stem back to the project I worked on in 2016-2017 with BlueMetal for Fidelity Investments' Equity Trading team, called Artis OMT.  Artis OMT has been on Fidelity's Equity Trading floor for over a year now, and will soon reach a year of full deployment.  While Artis OMT was WPF, this post looks at similar performance ideas in a similar but different platform:  Windows 10 UWP (store apps).

Artis OMT didn't start out able to handle 90Gigabytes of incoming data.  We had to use JetBrains tools to identify code that was bogging down or hanging the main UI thread.   That analysis, alone, is perhaps the subject of a different post, or more, some day.

When folks start thinking about UI Thread execution, the first thing most think of is Dispatcher.BeginInvoke().  This method is how you add workload to the UI thread.  I'm trying to talk about how to UNLOAD the UI thread, and/or manage your load so that the user won't observe UI freezes or lockups.

Here, however, are a few relatively easy ways to really make use of the extra cores in your CPU, and make your apps appear to perform much better:

Task.Run(() => { ... });
Classic depiction of processes running in sequence vs in parallel

The title of this says it all, really.  Push a workload off the current thread.  Use whenever you have long running processes that you don't have to touch UI controls from.   If you have timing dependencies, you can manage them with Task.When, Task,Wait, or even better, Task.ContinueWith().  Examples below cover this a little more.

Batch remote service calls using Tasks and WhenAll()

Service calls are low hanging fruit.  So often I see code that makes calls in series, waiting on the results of one before making the next call, even though the two calls have no dependencies on each other...  it's just so much easier to write the sequence case that folks let it hang.   await Task.WhenAll(...) is not as syntactically sweet, but still MUCH sweeter than having to set up an aggregate event.


/// Does one request at a time, holding up the entire process
/// at each step until it completes. Simpler code but....
/// Total time spent is the sum of all tasks' time.
public async void GetContentinSequence(Session session)
    var dbContent = await GetDatabaseContent(session);
    var webContent = await GetWebContent(session);
    var userProfile = await GetUserProfile(session);
    var userContext = await GetUserContext(session);


/// Executes all requests simultaneously, letting the default task dispatcher do its thing.
/// total time spent is no more than the longest running individual task, all other things being equal.
public async void GetContentinParallel(Session session)
    var contextTask = GetDatabaseContent(session);
    var webContentTask = GetWebContent(session);
    var userProfileTask = GetUserProfile(session);
    var userContextTask = GetUserProfile(session);

    var stuff = new Task[] { contextTask, webContentTask, userProfileTask, userContextTask };
    await Task.WhenAll(stuff);

    var dbContent = contextTask.Result;
    var webContent = webContentTask.Result;
    var userProfile = userProfileTask.Result;
    var userContext = userContextTask.Result;

Here's an example that makes this more clear:

var start = DateTimeOffset.Now;
var task1 = Task.Run(async () => { await Task.Delay(1000); });
var task2 = Task.Run(async () => { await Task.Delay(1500); }); //1.5 seconds
var task3 = Task.Run(async () => { await Task.Delay(1000); });
var task4 = Task.Run(async () => { await Task.Delay(1000); });
var tasks = new Task[] { task1, task2, task3, task4 };
Task.WhenAll(tasks).ContinueWith(t => { Debug.WriteLine(DateTimeOffset.Now - start); });

outputs something like:

As always, there's some overhead with task switching.  You'll notice that the time was just a few ticks longer than 1.5 seconds.

What if you can't unload the UI thread?  what if your long running process must interact with controls like a huge grid that needs to calculate an aggregation of a data set that lives in it?   

Here's an option...

DoEvents() erhhh... ummm...  await Task.Delay(...)

I once scrubbed references to Visual Basic from my CV and landed a job that had scrubbed VB from the job description.  I didn't want to work for a company that would hire a "VB-Weenie" and they didn't want to hire a "VB-Weenie", either... but there was VB6 work to do. 

One thing that VB6 had going for it was a concept called DoEvents().   It enabled you to give up processing the current method to allow any pending events to execute. It would then return to finish the calling method.

In C#, the closest equivalent, nowadays, is "await Task.Yield()" or await.Task.Delay(...).

Most folks talk about using "await Task.Yield()" at the start of an awaitable method to make sure the whole method runs asynchronously.  There's some sense to that.   More importantly, one can interrupt long running processes that must run on the UI in order to allow the UI to respond to user inputs.  In testing, I've seen that Task.Yield() often doesn't allow enough room for redraws of the UI.  Likewise, setting a Task.Delay of a 1 tick timespan isn't enough, either.  1 millisecond delay, however, does seem to suffice in my basic testing.

private async void LongRunningAggregatorOnUIThread(object sender, object e)

    await Task.Yield();
    var timeoutRate = TimeSpan.FromMilliseconds(100);

    var timeout = DateTimeOffset.Now.Add(timeoutRate);
    var value = 0L;
    while (true)
        if (DateTimeOffset.Now >= timeout)
            textbox.Text = value.ToString();
            await Task.Delay(1);
            timeout = DateTimeOffset.Now.Add(timeoutRate);

As always, use this very carefully.  This has overhead of its own, as well, that can cause performance issues.... including potential deadlocks.

Friday, December 8, 2017

Windows 10 IoT Core, C# & Azure IoT Hub for New England Microsoft Developers 12/7/2017

Just wanted to say thanks for inviting me to reprise my Boston Code Camp 28 presentation for the group last night (12/7).   I enjoy talking about development anywhere in the Microsoft stack, and I love that Windows 10 IoT Core + Azure IoT Hub spans a good range of it.  I have a bunch of other topics I'd be happy to share, especially in the Windows 10 domain. Check through this blog, I have a post for each that shares slides, but I know the presentation's a big part of the value of them.

These slides are really only a tweak of the BOSCC28 slides with the NEMD group title.

Sunday, November 19, 2017

MVP IoT with Windows 10, C#, Raspberry Pi and Azure IoT Hub

Boston Code Camp 28 is in the books as one of the greatest community events of recent times in my book.  Attendance was fantastic, we had amazing sponsors, and a ton of great speakers, but the thing that really made things hop was attendance.  I'm personally convinced it was the best attended Code Camp I've ever participated in.

As a presenter, I don't often get to attend as many of the amazing presentations as I'd like, but yesterday I found myself especially regretting that... there was just so much great content from so many great presenters. I did manage to get into more sessions than I usually do... how could I not?

Sure, you get a few "look at this cool stuff I can do" presentations.  These are great for folks looking for inspiration on the tough challenges.  I love the spirit of "look at this cool stuff you can do (if you apply your skills in a modestly different direction)".

This is why I do this MVP IoT presentation.  This presentation is about taking skills you already know and love (namely C# development) and applying them to what's classically though of as "embedded" development.  Yes, there's overhead in this approach...  you might have to use hardware that's slightly better equipped to handle Windows 10 IoT Core such as the Raspberry Pi 2b & 3b... but the difference is mute at small scale, and masked at large scale by not having to have a separate team with different skills. 

IoT apps on the Windows 10 IoT Core platform ARE Windows 10 apps.

The point I always try to drive home is IoT apps on the Windows 10 IoT Core platform ARE Windows 10 apps.  The very same exe you compile for your embedded device runs just as well on laptop, desktop, server, Windows 10 phone, et al.

I do regret the couple snags I had during my demos.  Still, someone approached me after the presentation with the idea that I should pre-record portions of my presentation in order to avoid these kinds of things.  I like to run live for several real reasons.  1)  I'm a coder, not a professional presenter... I don't often have time to polish my presentations to that level.  2)  Glossing over rough edges hides what development is.  Development is tough.  You have to have backup plans and contingencies.  My Raspberry Pi didn't want to connect to the guest WiFi, so I fell back to plan B, and moved on.  It's a real world scenario;  you hit a snag, but keep pressing on.

IoT is already about the last mile of the Sci-fi story, bringing Internet omnipotence to the fringes of reality, enabling the "Computer" of Star Trek (or the Cortana of the modern desktop) to reach it's potential (hopefully without becoming Skynet).
It's the stuff of science fiction... but it's not fiction.
Visual Studio 2017's ability to debug into a remote embedded device and make hot changes to a running executable is beyond top notch; it's the stuff of science fiction... but it's not fiction.

If you look through my post history, you'll see how this presentation has evolved over the past decade.  It's been an interesting evolution...  starting with connecting Windows Phone 7 to SharePoint.  Then Windows Phone 8 and SharePoint online (and the story got really muddy for a bit there).  Then CSOM hit and smoothed out the SharePoint side of things.  I changed the story to Field Enablement using Xamarin for iOS, Android, and Windows Phone with SharePoint as a back end for a bit. (It's a surprisingly compelling story, even if it's only academic).  Eventually I started focusing on UWP for Windows 10, and my love of small form factor development drew me back to Raspberry Pi. 

Finally, I'ved bridged off of SharePoint and started talking about Azure IoT Hub, which is the modern accepted best practice in the domain of this development stack.  This change happened so relatively quickly that if you notice, the synopsis for the session didn't mention it.  ( )

One can explore the code I developed for the demo at git hub, here:

That leads me to my final bit:  I am sorry I ran out of time in my presentation.  I was so psyched to show how to send telemetry back to Azure IoT Hub, and while I got to step through the code that sends updated reports, I did not get to explore any of what that looks like in the Azure IoT Hub portal, and didn't get to explore the event-driven API on the embedded side that allows you to send code with Device Twin down to a the device.

Here's the event that commits the post:

        private async void iotHubButton_Click(object sender, RoutedEventArgs e)




                using (var client = DeviceClient.CreateFromConnectionString(




                    var twinProperties = new TwinCollection();

                    twinProperties["MeasuredTemperature"] = manager.MeasuredTemperature;

                    twinProperties["HeaterPowerOn"] = manager.HeaterPowerOn;

                    twinProperties["ACPowerOn"] = manager.ACPowerOn;

                    twinProperties["Device_BOSCC"] = DateTime.Now.ToString();

                    await client.UpdateReportedPropertiesAsync(twinProperties);




            catch(Exception ex)






Click the image below to see the device I was using for the demo in Azure IoT Hub's Device Twin view.

Here's the resulting Device Twin JSON:
  "deviceId": "GraniteStHacker",
  "etag": "AAAAAAAAAAE=",
  "version": 8,
  "status": "enabled",
  "statusUpdateTime": "0001-01-01T00:00:00",
  "connectionState": "Disconnected",
  "lastActivityTime": "0001-01-01T00:00:00",
  "cloudToDeviceMessageCount": 0,
  "authenticationType": "sas",
  "x509Thumbprint": {
    "primaryThumbprint": null,
    "secondaryThumbprint": null
  "properties": {
    "desired": {
      "$metadata": {
        "$lastUpdated": "2017-11-14T01:48:45.8322179Z"
      "$version": 1
    "reported": {
      "MeasuredTemperature": 74,
      "HeaterPowerOn": true,
      "ACPowerOn": false,
      "Device_BOSCC": "11/18/2017 8:34:08 AM",
      "$metadata": {
        "$lastUpdated": "2017-11-18T16:34:20.1258514Z",
        "MeasuredTemperature": {
          "$lastUpdated": "2017-11-18T16:34:20.1258514Z"
        "HeaterPowerOn": {
          "$lastUpdated": "2017-11-18T16:34:20.1258514Z"
        "ACPowerOn": {
          "$lastUpdated": "2017-11-18T16:34:20.1258514Z"
        "Device_BOSCC": {
          "$lastUpdated": "2017-11-18T16:34:20.1258514Z"
      "$version": 7

Saturday, November 11, 2017

Intro to Natural Language Processing with LUIS

Here's the slides for the presentation I'm doing 11/16/2017 at the Granite State Windows Platform Developers (@WPDevNH) meeting in Salem, NH (at the Microsoft Store)

The group is primarily about Windows 10 app development (implying Universal Windows Platform, UWP).  That said, the group's been begging for sessions on AI and related services for some time.

Since I've been helping a client navigate LUIS lately, I figured an into to the LUIS service would be a nice way to break into this very useful service.

I reserve the right to tweak these slides up until I present them on Thursday, November 16th, 2017.

Please Join Us! 

UWP Equivalent for HttpUtility.ParseQueryString

Getting ready for my LUIS presentation at the Granite State Windows 10 Platform Devs Users Group (@WPDevNH), it made sense to demo LUIS using UWP rather than .NET classic.  (Join us, 11/16 at the Microsoft Store in Salem, NH... )

For a demo related to LUIS querying, I needed an alternative to System.Web.HttpUtility.ParseQueryString.  (based on this demo: )

I did a simple decorator of a Dictionary, adding a constructor to parse using WwwFormUrlDecoder, and overriding the ToString() to put it back together...

I whipped one up relatively quickly, but decided this would be a decent quick post.  Here's my alt code:

using System.Collections;
using System.Collections.Generic;
using System.Net;
using System.Text;
using Windows.Foundation;

namespace LUIS_Examples
    public class ParseQueryString : IDictionary<string, string>
        private IDictionary<string, string> _internalDictionary = new Dictionary<string, string>();
        public ParseQueryString(string queryString) :
            var decoder = new WwwFormUrlDecoder(queryString);

            foreach (var item in decoder)
                _internalDictionary.Add(item.Name, item.Value);

        public override string ToString()
            var sb = new StringBuilder();
            foreach (var aPair in _internalDictionary)
                sb.AppendFormat("{0}={1}", WebUtility.UrlEncode(aPair.Key), WebUtility.UrlEncode(aPair.Value));

            return sb.ToString();

        public string this[string key] { get => _internalDictionary[key]; set { _internalDictionary[key] = value; } }

        public ICollection<string> Keys => _internalDictionary.Keys;

        public ICollection<string> Values => _internalDictionary.Values;

        public int Count => _internalDictionary.Count;

        public bool IsReadOnly => _internalDictionary.IsReadOnly;

        public void Add(string key, string value)
            _internalDictionary.Add(key, value);

        public void Add(KeyValuePair<string, string> item)

        public void Clear()

        public bool Contains(KeyValuePair<string, string> item)
            return _internalDictionary.Contains(item);

        public bool ContainsKey(string key)
            return _internalDictionary.ContainsKey(key);

        public void CopyTo(KeyValuePair<string, string>[] array, int arrayIndex)
            _internalDictionary.CopyTo(array, arrayIndex);

        public IEnumeratorstring, string>> GetEnumerator()
            return _internalDictionary.GetEnumerator();

        public bool Remove(string key)
            return _internalDictionary.Remove(key);

        public bool Remove(KeyValuePair<string, string> item)
            return _internalDictionary.Remove(item);

        public bool TryGetValue(string key, out string value)
            return _internalDictionary.TryGetValue(key, out value);

        IEnumerator IEnumerable.GetEnumerator()
            return ((IEnumerable)_internalDictionary).GetEnumerator();