 |
My dear friend Bear. How are you this fine day ? Is that mud on your snout ? |
 |
Errrrr. |
 |
My knowledgable friend, you never learn about some things. Perhaps the honey you seek so assidously is not for you. Have you considered some nice nuts and berries? |
 |
Oh, never mind that Electron - seeking nuts leads to painful falls out of trees, and berry patches give a whole new meaning to thorny problems. Speaking of thorny problems, have you thought on what we discussed yesterday ? |
 |
I certainly have Bear, and I read those excellent documents you referred me too. I found Mr. Sutter's article very stimulating - he makes a very strong case. Nonetheless Bear, I am still concerned. It benefits me little to have a multithreaded system which does not work. |
 |
Yup. Any sufficiently powerful pattern has the opportunity to do significant damage to a schedule. Do recall that project we worked together on, the one using the factory pattern to create the business objects. |
 |
Oh, Bear, I wish you wouldn't bring that up. Silly thing kept making old versions of objects in our glorious new system, and then everything would fall down around our ears. It took weeks to track that down. However, since you bring it up, how am I to use something even more powerful like multithreading and not find myself in a worse predicament. It's not like you have that problem now, lying on your back and spouting wisdom, instead of working for an honest living. |
 |
Electron, don't be bitter - such is the way of things. Lets look at this multithreading issue in more detail. Do you agree that you can use this pattern in a wider number of projects than you initially felt you could ? |
 |
Yes, I can. And I can see why you felt I was being unneccessarily narrow minded yesterday. Nonetheless Bear, my initial objection stands. Many of my projects are simple. Our developers write a simple ASP.Net application that uses a web service to get some data, lets the user perform a few controlled manipulations, and then stores the results. |
|
You're certainly not alone in that effort. Electron, can you take us to one of those pages so that we can make a few rough measurements ? |
 |
Certainly. Lets use the Inventory Pricing tool, I'm particularly proud of that one right now. |
|
OK - it's certainly pretty |
 |
Indeed - we had the services of an Information Architect on this project, so the interface, in fact the fundamental usability of the system, is of much higher caliber than some of our other efforts. |
|
There's no substitute for a good IA. OK, lets fire up the task manager. |
|
Why ? |
|
Its' a cheap way to get simple measurements of what your computer is doing and get some guidance about how efficient your application is. |
|
Oh, OK. See Bear, how I can select an inventory item, and then the page is refreshed with all the information on the part I've selected ? |
 |
I do, I do - and I see you're using ATLAS. That's multithreading, you know. |
|
Yes Bear, but not multithreading my team is directly responsible for developing and maintaining. We get it for free, or at least almost free. |
|
True enough Electron. Now lets look at the graph of processor activity. Hmm, it really hasn't been doing to much. A spike right there in the middle, and then quiet for a little bit, and then another spike. Hmmm. So the first spike was when we requested the page, and the second was when we selected an inventory item. OK, Electron, tell me this. What would make this more efficient ? |
 |
Bear, you don't know what you are talking about! Nothing would make this much more efficient. Look at all we did, updating that page with the details on the part we chose. And in very little time, I might add. |
|
Oh, true enough. I wasn't meaning to belittle your fine work, my old friend. What made this inefficient was us - and there's no way to truly fix that. The slowest part of this task will always be the user, be they human or a stuffed bear. Multithreading would do nothing here. |
 |
See, Bear. What have I been saying all of this time ? Quot Erat Demonstrandum, that's what I always say. |
|
Uh - huh . Electorn, in my experience, you are far more likely to say 'Where's the beer, I'm thirsty' |
|
Speaking of which....... Ah, there it is ....... I was getting thirsty......... Bear, what are you doing ??? |
 |
This isn't the production system is it ? |
|
Nope, it's the testbed - but what are you doing |
|
Well, if its the testbed, is there any harm in choosing this action ? The COLA adjustment ? |
|
Nope - it will take longer though - it's going to go through all the parts in the inventory. |
|
I understand that from your excellent help you've put in this application. Excuse me while I attach to the server - I assume you're using the same password you always have ? |
|
Errrrrrr |
|
Ah, yes, you are - and we'll bring up the task manager on the server......... Good, it looks fairly quiet. Now to switch back to the brower...... This remote desktop tool is so handy........And we'll make a 20% cost of living adjustment to all inventory items to account for the dramatic increases in fuel costs.....Still driving that SUV, old friend |
|
Not for much longer - I'm getting a hybrid - but I'll miss the old girl --- remember all the expeditions we went on in her, camping at the mountains, skiing, the beach ? Can't fit any of that stuff in the hybrid. |
| |
Yes, but your savings in gas are probably enough to let you FedEx all that stuff to your destination... |
|
True enough. Ok Bear, so what's got your attention now ? |
|
Electron, look at the processor activity graph. |
|
Mnnnnm, it's rather spikey. |
|
It most certainly is - from this I assume you call the web service for each parts information, make the COLA adjustment, and then call the web services again to store the updated data ? |
|
That's it exactly! Nice. Simple. Straightforward. Why, I ask you Bear, would I want to put multithreading in that ? |
|
So the spikey graph is showing us that the server.....asks for a part....... waits for the data to come back from the web service...... changes the part data...... gives it back to the web service...... waits for the result...... and then goes on to the next part. |
|
Bear, I can't change the web service. It's not under my control. This is just the way things are. |
|
Think of this Electron - this process spends more of its time waiting for the web service to perform a requested action than it does actually doing anything. Just for the sake of argument, what if the web service were infinitely fast ? |
|
Well, it would certainly be done a lot quicker - but that isn't going to happen - plus, if it ever did then I'd have a new problem ..... the server would be so busy calculating it would never be able to serve up new pages. |
|
Quite true, but thats an issue for another time. Did you ever experiment with changing how you interacted with the web service ? |
|
As a matter of fact we did Bear - we found that if we had the service process multiple parts at a time it was considerably snappier, mostly due to the fact that we were using the database more efficiently. But it wasn't worth it, it made everything else too complicated. |
|
I understand that - it's easier for the business rules to focus on one part at a time. However, consider this.....
Say you had three threads running. The first is filling an input queue from the web service, the second is taking parts off the input queue and processing them, writing the results to an output queue, and the third takes parts off the output queue and sends then to the web service. |
|
Hmmm. Let me think.
So the input thread can go get a bunch of parts at once and dump them on the queue. The processing thread takes these parts one at a time off the input queue, applies the business logic, and puts the result on the output queue. And the output thread takes the processed items and sends them back to the web service. So - just because either the input or output thread is waiting for the service doesn't mean that the processing thread has to wait as well. |
|
Precisely Electron - you've got the very meat of it. Wouldn't that be more efficient ? |
|
Sure, if the input queue stays full - and the process thread is always running - but won't the input and output threads compete with the process thread for the computers attention ? |
|
Not really - after all, they spend most of their time waiting for the web service. |
|
Yes, that's true - but here's another problem - What if it's quicker to get information from the web service than it is to process it. Then we'd suck in a zillion input records and things would be worse as we ate up all the physical memory. |
|
True - so lets assume that there is nice logic in there to make sure all the queues are 'the right size', and that no one thread gets to run in a way detrimental to the others. |
|
Ah - ha! You have fallen victim to my clever ruse - I know that if you've dealt with all these issues that the multithreaded solution will be optimal - but I told you when we started this - these issues are beyond my staff. |
|
Yes, Electron - I already agreed that you weren't in the operating systems business. However, you now seem to be saying that there is value in multithreading, but it is a value you dare not try to capture - if the risks you fear were not there, would you still eschew multthreading, or would you take advantage of it ? |
|
Mmmm - OK Bear, I see what you've done here - and yes, I agree that three threads could yield much better performance than run. But feeding the queues, making sure nothing mysteriously seizes up, making sure the solution isn't so efficient it starves the other programs, ...... The rewards are great, but I have a family to feed and a mortgage to pay. And you're talking about serious risk here, my friend. |
|
I know Electron - you're a practical architect, and I mean that with the greatest respect. But lets look at this issue in abstract terms. The real development effort you expend is in communicating with the web service, and applying the business rules to each of the inventory items in turn. The rest of it, single threaded or multithreaded, is just so much plumbing. |
|
True.......... What are you getting at ? |
|
We have treated each of these operations, reading from the web service, applying the busines logic, and writing to the web service as atomic elements. We'be been talking about how they might communicate, and that they might run on separate threads, but we've never assume we were going to do any fancy multithreading inside of them. If we made what you've done multithreaded, we'd be changing the plumbing that connects the pieces that you've already created, we wouldn't be changing the pieces themselves. |
|
Yeah. Well, Bear, when I can go down to the application plumbing store and buy myself this kind of plumbing, maybe I'll think about it. Last I knew, there wasn't any such store. |
|
Quite true Electron - stores sell things. You can have this plumbing for free. |
|
Free - oh, great. Another marginally supported, poorly tested open source project ? Just what I need. Bear, that cure is definitely worse than the disease! |
|
Marginally supported - absolutely. Poorly tested, not so much, but any software could do with more. Electron, there may actually be something that would satisfy your needs, or at least show you the path to your destination. After our talk yesterday, you haven't already forgotten about your stakeholders, have you ? |
|
What about them ?! |
|
The shiny new computers they are buying that don't run the software any faster. The issues in Mr. Sutter's fine article. |
|
No, I haven't forgotten. OK Bear, I'll agree. If there was a way that I could have my people craft the individual tasks in a business process, and then have a framework I trusted to orchestrate all of these tasks...... |
|
You trust IIS and BizTalk..... |
|
Touche, Bear, touche. That's not funny. |
|
Electron, if I could show you that for a large class of business processes it would be possible for you to implement them in multithreaded form without ever having to dirty your hands with the elements of multithreading......... |
|
You're on. You show me how my developers could create multithreaded business processes like the COLA adjuster without having to know anything about multithreading and I'll, I'll,.... |
|
Yes ? |
|
I'll buy you a fifty gallon drum of honey, you pig. |
|
Bear. |
|
Whatever. |
|
OK, so you agree that multithreading could improve your systems in a number of areas, especially those where processing is impeded because of the need to wait for other systems to give you data, or take data from you. And if you could make that multithreaded while hiding all of the naughty bits, you'd add multithreading to your architectural pattern book. |
|
Absolutely. I don't believe it can be done, but truly Bear, I'd love to be convinced. |
|
Electron, an open mind is all I need. We'll adjourn for the day, and tomorrow we'll take up the nature of this system. |
|
Sounds good to me. Got any more beer ? |
|
Unfortunately my friend, you seem to have converted all of the beer to empties. I'll need to stock up on some more. It will be here for you tomorrow. |