A Day in the Life

A day in my life. Thoughts on leadership, management, startups, technology, software, concurrent development, etc... Basically the stuff I think about from 10am to 6pm.

8/29/2006

Passport Problems?



Maybe it’s bad luck or maybe bad karma...or maybe I’m just stupid. But I get myself into ALL kinds of trouble with Microsoft Passport. I have two accounts. One that is for work and one that is personal. So maybe that is the problem. Either way...I just don’t know.

The first time I ran into a Passport problem was about two months ago on the Microsoft Community Forums, I tried to login using my work account and I got "stuck" on a profile page. Nothing I did could get me past that page...for weeks...but that seems to be fixed now. Yea. (Microsoft screw-ups 1)

The second time was when I tried to login to the Microsoft Partner site and I used the wrong Passport account. That took awhile to figure out because I was so sure that I had used my work account and not my personal account to register. (Kim screw-ups 1)

My latest adventure with Passport is happening on the Microsoft Partner page. The site has been revamped...I know because I got an email about it. So I thought I would check it out. I tried logging in with one account and that failed (I got a message saying that I wasn’t a member, okay, wrong account), so I wanted to try the other account...this is where the fun starts. I am sad to report that I can push that Sign Out button ALL day long and nothing happens. It stays a Sign Out button.

Is it me? Is it the site? Is it Passport?

Current Screw-up Score:

Microsoft 1
Kim 1
Unknown 1

Am I annoyed? Yes

8/28/2006

Just thinking about processors, threads, performance, and scalability

Before I read John’s blog post for today I was thinking about multiprocessor machines. Probably because I was talking about threading in my last post. I was thinking about the maximum number of processors the Windows Server 2003 operating system can support. The 32-bit version of Windows Server 2003 supports up to 32 processors in one box. While the 64-bit version of Windows Server 2003 can support more than 32. link So...how much would one of these machines cost?

I went to Dell’s site and the box with the most number of sockets was the PowerEdge 6800 with four dual cores. By selecting the default configuration and only switching from a dual to a quad, the price was $19,107. Ouch.

I then went to HP’s site and found a couple offerings:

HP ProLiant ML570 G3 Server series which has four sockets and starts at $4599.
HP ProLiant DL500 Server series which has four sockets and starts at $6199.
HP Integrity Server series which supports 2-64 processors with no listed base price. Hmmmm.... This reminds me of eating at a fancy restaurant that doesn’t list the prices...if you have to ask...you can’t afford it.

I think that the numbers are interesting. There is absolutely no doubt in my mind that there are applications that must use threads to support performance issues. But considering how difficult it can be to write multithreaded applications, coupled with the price of machines capable of scaling via threads, it just doesn’t make sense to me from a cost/benefit perspective to use threading for scaling problems. I think that scalability is better served by using grid objects on a compute grid running on cheap single or dual core machines.

Just ruminating...

Concurrent Development: Required Personality Traits

I came across this post by Rob Walling. Rob writes about four personality traits that the best software developers have. I’m going to use those traits and explain why any developer who hopes to make the shift to being a concurrent software developer must find someway to draw those traits to the surface of their psyche.

Pessimistic

While I wouldn’t have used the term pessimistic, (I would have used realist), the idea is sound. You must confront the reality of your situation. Period. You are an engineer. It is your job to make sure that the applications work and to anticipate ALL the things that can go wrong. Because if you don’t find it...someone else will. And if that someone is a customer it can be bad for your company and maybe even you.

Anticipating the worst requires mental discipline, a comfortable knowledge of how the system and software work, and the willingness to test your assumptions. All of this can be learned.

If you are using threading as your concurrency tool, it is absolutely vital that you understand context switching and time slices. You have to make sure that threaded code can lose a time slice at any point, still produce the expected results, and not cause other threads to fail. This needs to be tested and not just by the test team but by you. And not just on a single processor box, but on a multiprocessor box. Test is NOT a dirty word. You should be doing it early and often. Because when things go wrong...a good engineer makes sure that they know about it before anyone else.

Remember, you are not in marketing...you are an engineer; anticipate the worst and plan for it.

Angered By Sloppy Code

If the code is sloppy...then how can you understand it? If you are using threads there will come a point in the development process where the only tools you’ll have for isolating a thread problem will be a log file and your knowledge of the code. When you get to this point...sloppy code can kill you. Concurrency developers don’t have the luxury of unclear thinking or convoluted solutions. Clean code AND a clean architecture make it easier to identify shared resources and potential problems.

"Someone who fixes a problem but doesn't take the time to find out what caused it is doomed to never become an expert in their field." – Rob Walling

If you try to fix a thread problem without understanding it...I can guarantee that you didn’t fix the problem...you just moved it. Thread problems often manifest when a time slice is released at just the right time and you’re not protecting something as well as you think you are. If you just fix the symptoms then the problem will manifest again and will be even harder to track down next time. Fix it when it happens and fix it right.

Long Term Life Planners

"Cause and effect, chain of events, All of the chaos makes perfect sense, When you’re spinning round things come undone...Welcome to Earth 3rd rock from the Sun" – Joe Diffie

Yes, I listen to county western music. I love that song because it is such a perfect example of how one thing affects another to the point where things just get nuts. And with threads things can get really nuts if you’re not careful. That is why planning is so important.

Concurrency should be planned into your application from the beginning but if that isn’t an option for you...plan how you’re going to add it. Don’t just sit down and start writing code. Figure out all the Pieces Parts. Hope for the best, but plan for the worst.

Once you’ve figured out where you can add concurrency and how you’re going to add it...you need think about the future. To support concurrent applications you have to add more processes to your software development cycle.

Put processes in place to protect the code. For example, your team may have fifteen people on it of which only two are responsible for the threaded code. Your two threading engineers should code review all changes made by the other engineers that could even remotely affect the threaded code. If you are the engineering manager don’t make the mistake of thinking that everyone "gets" parallel development, because they don’t.

Also put in automated build and test processes designed to catch threading issues as close to the code change as possible. This will make tracking down the problems easier. Don’t forget to add logging and log levels to your applications and to TRAIN your test team.

Attention to Detail

Well...I think the need for this trait is summed up in the first three traits. The idea of paying attention to details is tied up in mental discipline, planning, and testing. Don't be lazy...just do it!

Conclusion

Concurrent software engineers have to juggle a harder programming model than sequential software engineers. So make it as easy on yourself as you can. Writing code for parallel execution requires that developers learn to think differently, it’s not just me waving my hands here.

"It's not intrinsically harder to write threads, but developers need to get used to thinking that way and we need help from the tools," Reinders said. "In the serial world, it doesn't matter which order you do things or how you break them down." - article link...

Labels:

8/27/2006

Recommended ASP.NET webcast

When I’m learning a new technology I need to understand how it’s put together. (Basically understand the structure of the technology and then the base elements of how it works.) This is probably because I started my career working with DOS interrupts and Assembler. So in my quest to understand how ASP.NET works I ran across this great webcast that I think every ASP.NET architect or development lead should watch.

"MSDN Webcast: ASP.NET Under the Covers: Creating High-Availability, Scalable Web Applications (Level 300)"

I particularly liked the information pertaining to how virtual address space gets fragmented by small assemblies that align on 64KB boundaries; this means that there can be a lot of unused memory between the assemblies. With this increased risk of virtual address fragmentation, applications suffer out-of-memory (OOM) errors but the physical memory looks fine. Very interesting.

Improve Windows XP performance...

Here is a link to an article with tips to improve your Windows XP performance. Some of the tips I've used in the past and some were new to me. This is great because I’ve got an XP box at home that is just a dog, even with the changes I already made to speed it up. I’m looking forward to making it even faster.

8/25/2006

I Code Therefore I Learn

Microsoft has a lot of resources available to developers:

MSDN
Virtual Labs
Shows & Webcasts
Channel 9
10
Microsoft bloggers
Microsoft Chats
MSDN Magazine
Newsgroups
Microsoft Forums
Microsoft TechNet

And for third-party sample code and articles:

Codezone – Microsoft’s list of 3rd party sites, some of the links below will be found on Codezone

.netWire
4 Guys From Rolla.com
abstractvb.com
A1 VBCode
ASPAdvice
asp alliance
ASPWire
Code 101.com
Code Guru
Code Hound
Code Projectc
C# Corner
CSharpFriends.com
C# Help
C# Station
Code Comments
CodeSource.net
DevASP .Net
Dev Articles
DevAuthority.com
developer.com
Developer Land .NET
Developer Fusion
developers.net
Developers dex
DevX.com
DotNetBips
C# .Net Fun
DotNetJohn
dotnetjunkies
dotnet.za.net
dotnetslackers.com
Dotnet Spider
DNzone
eggheadcafe.com
Know dot net
Mycplus
sitepoint
vb accelerator
vb City.com
Visual Basic Explorer
velocityreviews

News Sites:

C# Online.NET - wiki
DotNetKicks.com – Digg for .NET
.NET Rocks! - .NET podcasts
TheServerSide.NET
wwwcoder
dotnetcat.com - wiki

Magazines:

Access/VB/SQL Advisor
Application Development Trends
CoDe Magazine
Dr. Dobbs Journal
NET Developer's Journal
SOA Web Services Journal
SQL Server Magazine
TechNet Magazine
Visual Studio Magazine
WindowsITPro

Information about .NET products, components, and tools:

LarkWare News – Mike Gunderloy is a very nice guy so when you find out about new tools...let him know
madgeek SharpToolbox
Dev Direct
Programmers Heaven
DevArchive.Com
World of .NET
Paul Thurrott’s SuperSite for Windows

And you know this isn’t even the tip of the iceberg. There are plenty of other sites for SQL Server, Excel, Biztalk, non-English sites, etc...that aren’t listed; as well as a very large pool of non-Microsoft bloggers. Someone said to me the other day that ASP.NET didn’t have as many online resources as PHP. Well, I don’t know if this is true but I am pretty sure that if it is true...it really doesn’t matter. There is too much and then there is too much. There is plenty of information for both technology choices, so that the decision between one or the other should be based on business needs and developer experience.

I <Heart> Virtual Labs

My next project is getting the Digipede Network to run behind an ASP.NET application. (I’m sooo happy to be back in .NET land again for a little while.) This means that I am busy learning ASP.NET. Microsoft has really done a great job of providing developer learning tools. Between the Virtual Labs - hands on labs hosted on a remote Microsoft machines, Shows & Webcasts - live and prerecorded webinars, videos, and podcasts, and technology specific sites like ASP.net, there is a plethora of learning opportunities.

There are a lot of things to like about the Virtual Labs:

1. I get to use the technologies without having to install all the software.

2. I get walked through a "doing something" with the technology.

3. I get to learn what all the little doodads are called, like smart tags and grab handle. So I’m learning the proper Microsoft terminology. I actually have a tendency to make up my own names for things if none are apparent, which can make communicating with me pretty interesting sometimes.

A few things I don’t like:

1. I sure could use some screen shots from time to time. I have had trouble figuring out what UI element the lab notes were talking about.

2. There are times when an explanation of why I’m typing something in would be helpful.

3. Running a lab during "peek" hours can sometimes result in very slow keyboard response.

But hey! I’m not complaining it is an incredible service and we are lucky to have it.

Concurrent Development: Pieces and parts...

I hope that you took my last post seriously. While kind of kooky the approach actually works and for those of you who are old enough to remember the shift to object oriented development; we need all the help we can get. Let’s say that you’ve taught yourself how to look at the world with the eyes an experienced multitasker. Now it’s time to start thinking about how to apply this new way of thinking to your code.

There are three main areas in concurrent program design: decomposition, communication, and synchronization.

Decomposition - the task of identifying both functions and data within an application that have parallelizable elements as well as identifying shared resources.

Communication - how the parallelizable elements communicate with each other and/or the rest of the application.

Synchronization - how to manage the creation, execution, and termination of the parallelizable elements such that shared resources are not corrupted or locked out and the expected results are achieved every time.

Start and end with decomposition because you will need to continuously exam your application for opportunities and potential problems. Any engineer using concurrency must approach software development as a big picture activity. Generally this has been the responsibility of the architects and leads, but now it’s yours as well. If you’re going to use concurrency in your applications you MUST understand how your application is put together. You must be able to identify:

1. Parallelizable areas that perform the same function over and over, but act on different data. You will often find these algorithms in loops.

2. Parallelizable areas that are not algorithmically connected and can execute at the same time. The obvious example of this is a UI thread and a background worker thread.

3. Critical areas of code that must never be executed in parallel. These codes sections are often found around shared resources that must be accessed sequentially.

4. Large bulk processes that can be easily split up and processed in parallel. An example of this is the breaking up of a large EDI (Electronic Data Interchange) file for ETL (extract, transform, and load).

Know your code. Know your tools. Know your business.

Labels:

8/24/2006

Concurrent Development: I think therefore I am; I am therefore I think

Learning to develop using the concurrent model requires a mental shift in how a developer problem solves. This mental shift can be difficult and to help demonstrate this: try patting your head and rubbing your stomach at the same time. Too easy... how about: hold your screaming infant while simultaneously checking the temperature of the formula without dropping the kid or the bottle. Learning to multitask in your day to day life will help you learn to multitask in your software because you learn to identify WHEN it’s safe to multitask. It’s probably not a great idea to try and check the formula while holding a screaming baby at 3am in the morning (assuming that you’re half awake). But we’ve done it haven’t we.

Change is a process. Most engineers can teach themselves to multitask and the action of multitasking exposes people to the idea of doing more than one thing at a time. If the pathways in your brain are not wired for thinking in parallel, then you have to start building those pathways. You have to train yourself.

This reminds me of my step-father who used to constantly tell us kids, "If you’re going into the kitchen, take a dirty plate with you." Thanks Gary, that was early training for concurrent software development techniques.

What you need to learn to do is:

1. Identify multitasking opportunities.
2. Learn to judge how "safe" it is to do those tasks in parallel.
3. Learn to distinguish between similar parallel activities, conjunction parallel activities, and always needs to be sequential activities.

While there are some folks who already have all these skills, many folks don’t. So take a little time and learn it. Train your mind by using your body.

More later...

Labels:

8/23/2006

Concurrent Development: Spotting the Wave

Over the years I’ve had the pleasure of working on several multithreaded applications but rarely have I been involved with the projects from the beginning. Usually I’ve been brought in because the teams couldn’t stabilize the systems. While this is a great ego boost and a chance to play the white knight – it’s a pain. I’ve had a lot of time to think about grid computing since I started at Digipede and very early I recognized the relationship between threads and grid objects. Both are tools that support concurrent software development and both have their place in solutions requiring high performance and scalability.

For those of you who haven’t been keeping up with the latest hardware trends. CPU clock speed has reached a major roadblock. The general computer buying public (this would be us) is not going to see new processors with faster chips until the hardware vendors figure out how to either reduce the generated heat or a how to more efficiently draw the heat away. To continue to bring us the new and faster computer chips that we’ve become accustomed to, the hardware vendors are adding processors to the core. Dual-core machines are already on the market and they are not restricted to servers. Those chips are going into desktops and laptops as well. And it has been predicted that the hardware vendors are not going to stop at two. I would take that bet.

In the past our applications would automatically reap the benefit of faster CPUs but that is not going to be the case with the multi-core machines. We, the software developers of the world, are now going to have to work to make our applications faster. This means that software developers are going to have to learn how to build software applications that take advantage of concurrency.

There are many differences between sequential and concurrent software development. Sequential software development boils down to the idea that there is only ever ONE part of your application running at any time. Even when it looks like there is more going on...say when you send a message, catch an event, run something asynchronously (without threads), etc... There is only one part of the application running and there can BE only one part running.

With concurrent software development, one or more parts of your application can be executed at the exact same time. I say can, because concurrent software applications that are run on a single processor machine are sort of a hybrid sequential/concurrent application. While parts of the application are capable of running at the same time (in parallel), there is only one processor and the single processor acts as a bottleneck. The operating system assumes responsibility for switching (time-slicing) between all the different threads and processes running on the computer. Barring the concurrent application on the single processor case; concurrent applications are designed to take advantage of multiple processors and of the operating system’s time-slicing capability resulting in the improvement of an application’s performance and scalability.

This is the beginning of a series of posts on concurrent software development; it is a journey that much of the software development community is going to have to take. I hope that the information that I share here will be make the transition from sequential to concurrent development easier.

Labels:

He was lost and then found...

I’ve mentioned before that I LOVE startups and small companies. One big reason for that are the teams. While I think that large companies have the ability to build teams, I’ve found that I’m much more likely to land on a team while working for a small company. I’m thinking about this today because my friend Jeff Mackay turned up. Shortly after I moved to California I lost track of him. And today he found me. Yippeee!

Jeff and I worked at Kaseworks together. We got drunk together, built and designed products together, complained together. A defining project was the Kase:Set++ project. Kase:Set++ was the C++ code generator that shipped with IBM’s first release of their C++ compiler for OS/2. If my memory serves me right Jeff and I turned that product around in a month. Did we live at the office? Yep. I remember sleeping under my desk a few times...just one more compile...

It was a very satisfying journey that we took together. And we built something that we were proud of. I remember Jeff laughing and telling me that we had to stop work on the Notebook module because IBM wasn’t ready. We were pushing the big guys, and while that was a minor blip in my life, it was a shared moment of feeling exhilarated because we "beat" IBM at something. Our friendship was forged in the fires of creativity and on the stresses of competition. Good natured competition between engineers with a passion for software, driven to be better than anyone else. Having teammates like Jeff helped make me a better engineer.

While the pressure and work of startups aren’t for everyone, the friends I have gained, the teams I have been on, have all made this an incredible journey.

Jeff just started blogging here and he’s looking a little scruffy in his photo! But I know he’s not afraid to write (he had a C++ book published, didn’t he just) so I hope to see some great things....No pressure Dude!

8/21/2006

For a good laugh...read these

I’ve been meaning to put together a blog post of my favorite links. So here it is. If you know of other bloggers who write like these folks...let me know. I find these blogs refreshing, honest, and most of them extremely funny. And for the record...I KNOW I have a warped sense of humor. I’ve accepted it and so should you.

Too funny for words
Corporate Hallucinations
dooce
Bug Bash
The Dilbert Blog
Sand Hill Slave

Very Interesting
What I’m Not - She’s taking me on a journey that I’ve often fantasized about. While she is having adventures I would never have, I’m loving living through her. And she is a very good writer. I just wish she could write more often.

8/16/2006

For me, VS2003 Server Pack 1 is a bust

I just installed Visual Studio .NET 2003 Server Pack 1, as I have written before here and here, I have been experiencing instability (i.e. the IDE is crashing hard) with VS2003 ever since I installed VS2005 on the same machine. I am sad to report that the service pack DOES NOT solve my problems.

It is very easy for me to reproduce two of the crashes:

The Properties crash:

1. Launch Visual Studio 2003.
2. Open a solution.
3. In the Solution Explorer pane, select a project.
4. Right-click on the project and select Properties at the bottom of the context menu.
5. Bam, "An unhandled exception has been caught by the VSW exception filter." and Microsoft sends itself the error information.

The Server Explorer crash:

1. Launch Visual Studio 2003.
2. Open a solution.
3. From the menu bar select View->Server Explorer.
4. Bam, "An unhandled exception has been caught by the VSW exception filter." and Microsoft sends itself the error information.

I don’t really need Server Explorer, but I do need to configure my project properties. On the plus side, at least my project file hasn’t been trashed. (Knock on wood)

8/11/2006

COM...the gift that keeps on giving

Here are some more things I learned today and all of these parts are related to the same program halt....

TODO: <File description>

I don’t know exactly what triggers the MFC error message box with the text, "TODO: <File description>". But I now know that I have a good reason to fill in all the VS_VERSION_INFO resources in my projects. Under some circumstances Microsoft pops up the message box below, obviously I couldn’t find any documentation that tells me exactly when Microsoft will do this, but I know it can happen.



To identify which part of the project triggered the error, update the FileDescription field in all the VS_VERSION_INFO structures in all your projects. That way when it goes you’ll know what assembly/dll was involved.

In Visual Studio open your project's the Resource View and under Version you’ll see VS_VERSION_INFO, change "FileDescription" to something unique.

EEFileLoadException

I haven’t exactly tracked down why this exception is being thrown. Microsoft doesn’t document it. But Microsoft does document the exception FileLoadException. Considering that I’m calling a managed assembly through an exposed COM interface from an unmanaged C++ executable, the error does fit. The description for FileLoadException is "The exception that is thrown when a managed assembly is found but cannot be loaded."

For some reason the description triggered some dormant brain cells, probably hanging around from when I was younger, which caused me to look in my Event Log. So I opened Event Viewer and I found that I had a .NET Runtime error that corresponded to the time I got the EEFileLoadException. Hmmm.

.NET Runtime version 2.0.50727.42 - 
Fatal Execution Engine Error (79F97075) (80131506)

Okay, this is more information but...what does it mean? Searching on the number 80131506 from MSDN of course doesn’t get a hit (if you hear a really loud sucking sound, that would be Microsoft search...sucking!)

First-chance exception at 0x7c81eb33 in MonteCarloPiApp.exe: 0xE0434F4D: 0xe0434f4d.

I also got a message box with the above error. Not much information available for this one, but I did find some recommendations about not running the application inside the debugger. So, I launched my program outside the debugger, got the "TODO message" box and selected the "Debug" button, which launches the debugger and sweetness... I get a "COMException was unhandled" error with an HRESULT of DISP_E_MEMBERNOTFOUND and a nice stack.

System.Runtime.InteropServices.COMException was unhandled
Message="Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND))"
Source="System.Windows.Forms"
ErrorCode=-2147352573
StackTrace:
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at g.a(Delegate A_0, Object[] A_1)
at Digipede.Framework.Api.DigipedeClient.d(JobStatusEventArgs A_0)
at Digipede.Framework.Api.DigipedeClient.f(Object A_0)
at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

That’s something I can work with.

Updated formatting problem

I want my Groups!

Googles UI has changed. What a pain in the butt. I use Google for work which means that I am often looking for code samples to clarify syntax and techniques. While for most users removing "Groups" isn’t that big a deal...for me it’s huge. Google has now added an extra button click and a mouse move for me to switch from "Web" search to "Group" search.



I suppose I could try to play around with Google’s personalized home page to see if that gets around the problem but right now I don’t have time. I did do a quick look to see if it would be easy, I basically just want the usual Google home page with the top links I need, but the personalized home page has a lot of crap on it which will slow down my page load time and there is no obvious way to set the links I want.

I’m sooo not happy about this.

Where Oh Where is my DISPID???!!!!

Life is such a journey. And sometimes what is old is new again. For those of you who have been reading my blog for the last 2 months you know that I’ve been working on a C++ COM sample for the Digipede Network. I’m not working on this full-time so I’m not a complete idiot for not finishing yet! But I’m learning new things and remembering old things. I often feel like I’ve forgotten more software techniques and technologies than I remember. And today is no exception. The focus of my interest recently has been creating a sink (to handle Digipede events). One of the problems I ran into is without access to the Digipede source code, how would a developer know what the DISPID values are to hook up the sink? How should my code define the event when one of the values I’m receiving is defined as an object?

Well, here is the answer to that part of the puzzle.

Steps:

1. From your Visual Studio environment, from the menu bar select Tools->OLE/COM Object Viewer. You now have the OLE/COM Object Viewer application open.
2. From the OLE/COM Object Viewer’s menu bar select File->View TypeLib.... In the Open dialog box navigate to a Digipede.Framework.dll file and select the file for opening. My Digipede.Framework.dll is located in "C:\Program Files\Digipede\Framework SDK\v1.2\Net1.1".
3. Now what you should see is the ITypeLib Viewer window with the Digipede.Framework.dll’s type library displayed.

We are now at the point where we can get important information that we need. In the left hand column is a list of all the methods and interfaces available from the Digipede.Framework.dll file. Right now I’m interested in the IDigipedeClientEvents interface. So I expand "coclass DigipedeClient" and from there I can see the IDigipedeClientEvents interface. I then expand the "Methods" and select "JobSubmissionCompleted".




Here is what I see in the right-hand box:
[id(0x000003e9)]
void JobSubmissionCompleted(
[in] VARIANT sender,
[in] _JobSubmissionCompletedEventArgs* e);

So to get the DISPID that I need I convert the number found in the id, 0x000003e9, from hex to decimal, and I have my DISPID value which is 1001.

I also see that the object value is converted to VARIANT.

I now have two important pieces of information. The DISPID value for JobSubmissionCompleted AND a prototype definition that C/C++ can understand. So the information is there and now I know how to find it.

8/10/2006

For your viewing pleasure...

I had a great time in Fresno last night talking to the Central California .NET User Group about concurrency, threads, and grid objects. It was a great group of people and I think we had some good conversation. I’ve had several requests for last night’s presentation. Click this link to download a zip file containing the presentation and the thread sample code.

Don't forget to get your free copy of the Digipede Network Developer Edition!

8/07/2006

Out and About – Aug 9th, Fresno, CA

This Wednesday, August 9th, I’ll be presenting at the Fresno .NET User Group. I’m going to be discussing concurrent software development, how threads work, and grid computing.

Year after year the hardware industry has been making our computers run faster and faster. But they have reached a plateau, we aren’t going to see an increase in clock speed for awhile. What we are going to see is more onboard cache and cpus. No more "free lunch" for us software engineers. Now we have to ensure that the performance improvements come from our software. And that means concurrent software development.

I agree with Herb Sutter’s assessment that the software industry is ready for another paradigm shift as significant as the OO shift. And like the OO shift it’s going to hurt and some of us aren’t going to be able to make the change. I’ve been building multithreaded applications since 1993 and I’ve made a few observations. First of all, multithreaded development is very different from sequential development. Second, multithreaded development is not intuitive, most people use threads and have no idea what is really going on. That is why the threading part of my presentation is going to talk about what is really happening in a threaded application.

Here are some links that will be useful to read before the presentation:

Multi-core chips provide power but make development tough
"Tom Halfhill, an analyst for In-Stat's "Microprocessor Report" in San Jose, says some software developers are "tearing their hair out" over the new CMP systems. "Rewriting the software for multi-threading is a lot of work, and it introduces new bugs, new complexities, and the software gets bigger, so there is some resistance to it.""

"But the CMP train has left the station, whether software developers like it or not. Intel says 85 percent of its server processors and 70 percent of its PC processors will be dual-core by year's end."

The Core Issue
"The biggest learning curve will be for programming teams that target consumer and business desktops. Until now, nearly all such platforms used one single-core processor. That meant that thread management was handled in software, not in hardware. While multithreaded applications would be slightly more efficient in a multitasking environment, the benefits of threaded designs were rarely emphasized by architects. Deadlocks and race conditions could be managed by the operating system. In short, programmers didn’t have to think about it. "

The Race is On to Debug Dual-Core Deadlocks
"Deadlocks...Race conditions....Detecting either error is difficult because collisions don’t always occur, so pinpointing the problem is a matter of timing, said Ken Cowan"

"Designing for concurrency is about getting a clear focus on how to decompose a problem, added Intel’s Reinders. "You are asking: ‘How do I break this program up?""
Concurrent software development requires a more structured approach to design, development, and testing. Those engineers and testers who grok the concurrent model are going to be worth a lot of money and are going to be very employable until the ability to use concurrent methodologies is as common as the ability to use OO methodologies. Wednesday’s presentation should get you heading in the right direction.

Update: Yes slides will be available. I will need to talk to Gustavo to find out the best distribution method. It may be that ya'll will have to send me an email and I will send them off to you. I didn't see a download section on the website.

Labels: