# Friday, August 20, 2004

So I've been playing with the idea of how you could get deterministic behaviour out of managed code.  Of course the party line is that it's not possible, but to me that's just throwing down the gauntlet.  They also say you can't suspend and resume a managed thread, to which I replied “Yeah? Watch me!”

This was fueled when I was at DevCon and sat in on a lab of Nat Frampton's where you simply create an ISR that responds to a contact on a serial port pin.  I wondered “well why the hell can't I do that in managed code?”  No reason really - I mean it's simply setting up an event to fire when an interrupt is received, and all of that can be P/Invoked (I haven't actually written the code yet, but there's nothing magic about it).  The problem comes with determinism.

Conventional wisdom says that the GC suspends all managed threads when it's doing its work (which can be annoying in most cases).  If this were to happen while you were doing your ISR work, you could get a really bad outlier.  So your system responds in milliseconds most of the time, but occasionally it takes a few seconds.  That's unacceptable - a box flies of the conveyor and hits the floor, making a mess.

So how do we handle this?  How about setting the GC thread priority to 255 at the start of your ISR, then back to it's original priority afterward?  To even better handle it, your ISR priority needs to be set high.

How do we proceed then?  We need the GC thread handle to manipulate its priority.  In comes the toolhelp libraries.  I wrote a ToolHelp wrapper for the SDF earlier in this quest, but I just realized yesterday I only had the PROCESSENTRY32 stuff done, not the THREADENTRY32, so I spent last night doing that piece.

Still, the THREADENTRY32 only has a ThreadID - how are we to determine which thread is the GC as opposed to all the other threads we may have in our process?  Well, I ran a quick check with a slap-together process viewer app based on my new toolhelp wrappers and I see this:

Notice the Priority 248 thread then think about managed priorities - there are five ranging from Lowest (0) to Highest(4), which presumably equate to 255 to 251, though I've yet to check.

My initial thought was that the 248 priority might be the GC, after all it would make sense that it's higher priority, though I also recall that all manged apps need 3 threads.  So why do I have 5?  Well the answer is that this was running through the debugger.  When run stand-alone, I get 3 threads, all with a priority of 251.

So where does that leave us?  Well first, it's evident that 251 is “Normal” priority, so I'll need to map out the actual values for the managed equivalents, but more importantly we still have no way to uniquely identify the GC thread (that I've found anyway).

Right now that's the show stopper.  If you've got any ideas on how to reliably identify the GC thread handle, I'd love to hear them. 

I guess on the plus side, outside of the designer work, it's only about 10 lines of code to create the process viewer you see here.  I'll probably add a few features and turn it into a sample for using the SDF.

Friday, August 20, 2004 12:49:41 PM (Central Daylight Time, UTC-05:00)  #     | 
# Tuesday, August 10, 2004

Man, I've been asking for it for sometime and finally here it is, a full explanation of how the GC works in the CF!  Yet more required reading for the CF developer.

Tuesday, August 10, 2004 9:18:58 PM (Central Daylight Time, UTC-05:00)  #     | 
# Tuesday, August 03, 2004

Here's an article I found while browsing Casey's blog, and I must say it's quite simple as well as insightful.  Now as any good Linux advocate would do, Paul maligns Microsoft - I'm not here to say that's good or bad, my views have already been stated - but the overall observations are right on target.  I know several great developers, and every one of them fits this model.

Tuesday, August 03, 2004 12:23:30 PM (Central Daylight Time, UTC-05:00)  #     | 
# Monday, August 02, 2004

Relative newcomers to the software industry, as well as a lot of people looking to get software done often ask some variant of the question “why does it cost so much to contract a developer?”  It might be disguised as “Why would I pay that much for a 3rd party component?” or “I can hire a junior programmer for a year for what they want for this!” but it always boils down to a misunderstanding of a value equation.

If a contractor quotes you $80 and hour you might be quick to say “that's about $160k a year!  Screw that!” but that misses a lot of things.  Leave out the fact that the contractor has to pay insurance, workers comp, FICA and all the overhead of a business.  Lets focus on what you're buying. 

You're not just buying an hour of that person's time.  You're buying the years of experience doing other work they have.  They're going to have seen far more problems and srewed up applications than a junior programmer will see in even their first 2 years.  You're buying access to a portfolio of base code they can draw from that is largely tested and true.  You're buying the late nights that they spent on past project pulling out their hair so that pitfalls are quickly avoided on your project.  Essentially you're paying for a much better ability to control the cost and schedule of your project.

So you're still thinking “it still seems expensive” are you?  Well face it, you can't sell an hour more than once.  If the contractor is selling you a product, you're getting a pro-rate on the hours spent developing the product because you're sharing the development hour with all of the other people buying the product.

Does it always make sense to contract out?  Of course not, but next time you're project has shot past a delivery deadline or gone overbudget and think about the experience base you have working on it then ask yourself “would having this project where the GANTT chart says I should be be worth the cost of a consultant?”

Monday, August 02, 2004 10:25:22 PM (Central Daylight Time, UTC-05:00)  #     | 

Wondering what the CF 2.0 brings to the table?  Wondering how the SDF enhances it and bridges the gap from 1.0?  Take a look at Peter's new poster.  A picture is worth a thousand words, but a diagram tells an entire story.

Monday, August 02, 2004 10:09:41 PM (Central Daylight Time, UTC-05:00)  #     | 
# Monday, July 26, 2004

I'm installing Platform Builder 3.0 so I can do some legacy support and when it prompted for Disk 10 it occurred to me that those of us who bitch about how long it takes to install Studio 2003 need to do a sanity check.  Remember the days when Office was something like 30 1.44 floppies?

Thank goodness for Virtual PC - I'll only have to do this once.  If you're a developer and not familiar with VPC, go check it out.  I think it gives Studio competition as one of the top productivity tools for developers.  Hell, I have half a dozen PCs without having to buy all the hardware, and it's easy to load to a known configuration.

Monday, July 26, 2004 4:49:36 PM (Central Daylight Time, UTC-05:00)  #     | 
# Sunday, July 25, 2004

Well we started the coding competition a few weeks ago now, and the suspense is killing me.  We seem to have a lot of interest (over 4000 hits on the main Wiki page for the competition) but since it'll be a while until submissions start coming in I've got no idea how successful this is going to be.  Is anyone actually writing something for it?

Sunday, July 25, 2004 12:11:17 PM (Central Daylight Time, UTC-05:00)  #     | 

In case you've missed the news, Neil and I are doing a Webcast this Wednesday on MSDN.  If you're using the SDF, send us a screen shot and we'll try to include it somewhere in the presentation.

Actually I hope it goes well.  I started out putting together the PPT, but then I got sidetracked with some major shakeup at my day job, and then my home PC died (I think the power supply on the motherboard crapped as it won't even BIOS post) and I've not had the time or the cash to get back on it.  I feel bad stranding Neil like that, though I've seen him pull some amazing stuff out in short order, so I'm sure it'll all go well.  Basically if it goes great, as I expect, Neil gets all the credit.

Sunday, July 25, 2004 12:05:41 PM (Central Daylight Time, UTC-05:00)  #     |