Its funny because its true. When there’s property setting or UI resizing or several other common UI related problems, putting the next statement on the Dispatcher to let an operation complete first is just the trick. Handy as Duct Tape. Case in point, the focus at startup issue.
The Lab sponsored a ski trip on Saturday to Windham Mountain. It was an awesomely awesome trip. Great weather, great company, and as far as I could tell, a great time had by all.
Goodbye ThreadPool & BackgroundWorker,
At this month’s .Net Meetup, David Barnhill, gave a great presentation on Multithreading in .Net 4.0. While the internal features are just upgrades, support for new syntaxes and keywords in a lamda style will make the current thread starting styles obsolete. Task Parallel Library is now the way to go. The Mandelbot Set demo was instructive and visually pleasing.
You can download David’s multithreading samples here.
Another David also presented on mutlithreading in PLinq.
DryadLINQ is a simple, powerful, and elegant programming environment for writing large-scale data parallel applications running on large PC clusters.
Reactive Extensions – Rx
Rx is a library for composing asynchronous and event-based programs using observable collections.
I’ve heard only great things about the Rx library, but David B. noted that the support and upgrade path is somewhat nebulous at this time.
I highly recommend this meetup.
This is the city after the meetup. Its an interesting area, a few blocks up from times square.
Word of the week: Blend·a·bility
With MS Expression Blend becoming more and more important in our development, we strive to maintain code that doesn’t break the UI designer features of Blend. We call this maintaining blendability.
Basically, Constructor and OnApplyTemplate methods for visual elements need to be respected and not throw errors when loading in design time. Constructor issues often come from dependency injection which Blend doesn’t supply. In this case making a default constructor can solve the problem. Code in the OnApplyTemplate should also respect nulls often caused by lack of dependency injection. Alternatively, you can check for design time with this code:
I’m reading Concurrent Programming on Windows since everyone @Lab seems to know more about threading than I do. Like most of the books I’ve been reading lately, this one weighs in at about 1,000 pages. I’d recommend it for anyone who knows a bit about the concurrency infrastructure but wants to know it all. Even so, there were some places where I felt a detail was missing, but 1,000 pages is plenty.
Here’s some interesting things I learned in the first couple hundred pages.
New threads in .Net will allocate 1MB for the stack on creation.
The total processor limit (including logical processors) of 32/64 in windows is mostly because of the CPU affinity mask which is 32 or 64 bits depending on windows version. This paper (Windows Support for Hyper-Threading Technology) supports that statement for Windows 2003 server. I can’t find a good reference to support this for Windows Server 2008.
The native (OS) limit for waitable objects (WaitForMultipleObjects) is 64, but .Net supports more.
I was interviewing with an interesting company the other day and I was asked how I would achieve the maximum throughput for a data feed of financial instrument quotes (not just stock quotes, but maybe foreign exchange, or bonds, etc. — its just an example, but I like to generalize :).
So we worked through the problem a little and as always there’s a couple things I left out that I could have said, but I think I did ok. My last statement was — doing it this way will be pretty good, but probably still not good enough. There’s something in me that just wants to optimize and admitting “not good enough” bugs me. The next day I was doing normal stuff and an interesting solution struck me out of the blue. Multithreaded Stacks, enough said.
So I set out to make a demo program to test the theory and lo and behold, you can easily push 50,000 quotes per second through a WPF application! 50K! On my crappy 2 year old duo 1.66GHZ/T5450. I couldn’t believe it. Take that AJAX.
It took a while to setup the demo program and I didn’t get to anything I consider innovative or advanced, but I don’t think I’ll be needing any Multithreaded Stacks today. Just seeing 50,000 quotes flowing through was enough for me.
Here’s the test program:
Mind you its just a demo. The quotes just consist of a random 3 letter id and a random price. But it does have a fun interactive graph thanks to Microsoft and the quotes do update in the grid. Actually all the numbers you can see in the pictures update through the automagic of WPF databinding. I even colored the quote process count with databinding. This isn’t your daddy’s old Windows Forms, this is W P F. This actually does more with less effort. MS may have gotten something right.
The app is all about allowing the user to modify different parameters and combinations that may affect the system.
On the left side are all the parameter settings. I’ve really just been playing with the Calls Per Second and Quotes Per Call options. I made 2 quote servers, one in WCF which is a little flaky at higher revs and one that runs a timer to send quotes from the ThreadPool within the application. I did the WCF first, because it seemed to replicate the problem domain, but its not really germane and I’m moving away from it.
The timer tick, simulates a data push, that I’m calling a “Call”. Within each data push, the number of quotes requested is sent. Multiplying “Calls per sec” and “Quotes per call” together gives you the expected quotes that will be pushed at the interface. I say expected, because the implementation of the “quote generator” yields less than the expected amount.
The calls per second can only go so high before it stops increasing the quotes generated number which displays on the bottom statusbar. This is probably because it comes to the resolution limit of the simple System.Timers.Timer I’m using. In the picture above, its set to 66 calls per second. Setting it higher does not increase the number of quotes pushed. Setting the quotes per call higher will increase the throughput and the UI for displaying quotes only gets sluggish over around 60K per second. CPU usage at 55K quotes per second is only 30 – 40% so maybe I could even do better.
I just put the quote display in a simple ListView/Grid:
Those quotes are jumpin’ 5 times per second. Take my word or download the code and see for yourself.
This statusbar shows Snapshot Quotes Per Second (TPS — I use the word Tick and Quote interchangeably — bad habit) at 59,165, Expected Pushed Quotes at 103,563 and Total Processed and Total Served (Pushed) Quotes within 1000 of each other. Either the consumer is 1/60 of a second behind the producer or just as likely there’s a synchronization issue between those 2 numbers.
You can download the code here and run in Visual Studio or stand alone. Just hit the Start button to see things go. Of course the code is AS IS, NO WARRANTY and freely distributable. See here for additional warnings.
If anybody’s interested I’ll do some more writeups on what’s going on in the code.