Peter Ritchie's MVP Blog - All Comments

re: Sudden "...you must have Terminal Server User Access permissions on this computer." Error.

Davide — Fri, 20 Nov 2009 13:08:04 GMT

Thx a lot: this is the only way I found to solve my problem!

re: Thread.Sleep is a sign of a poorly designed program.

PeterRitchie — Sat, 14 Nov 2009 13:56:21 GMT

@Richard. Right, using Thread.Sleep(1) will allow any other thread to take control of the CPU for at least a time-slice.

The question is a little misguided. The parameter to Sleep is the number of milliseconds to sleep. The fact that we're using 1 millisecond as a parameter means it's *really* difficult for any number of threads to be calling Thread.Sleep at the very same time. Then, there's the fact that only one thread at a time per processor is actually running...

Your question suggests to me that you want to dip into thread prioritization. You want to periodically do no work so other applications can do some. But, you don't know what those other applications do or whether stopping your work will benefit them at all. I wouldn't suggest writing your application to do this; there's no way to do it correctly without being the operating system. Using Thread.Sleep(1) in your threads is enough for the operating system to allow other threads to be responsive. It works remarkably well.

Are you using Thread.Sleep(1) and seeing that other applications are being starved of CPU?

re: Thread.Sleep is a sign of a poorly designed program.

Richard — Sat, 14 Nov 2009 08:51:32 GMT

We are looking for a way to relinquish CPU cycles to other applications in a milti-threaded application. If we use sleep.thread(1) in each thread then my assumption is that our other threads will take the CPU.

The question is...how can we use thread.sleep(1) on all of our threads simultaneously so that CPU cycles are open for other applications?

re: Upcoming C# 3 Guidance From Microsoft

PeterRitchie — Wed, 04 Nov 2009 15:38:46 GMT

@Lijo: I don't know of any books that specifically associating language features to SOLID principles. There's a couple of books that have information about SOLID principles (among other things) and C#. Some of the principles would inherently require specific language features (like DI and Generics):

Robert/Micha Martin's Agile Practices and Patterns in C#: www.amazon.ca/.../0131857258

Karl Seguin's free Foundations of Programming eBook: http://bit.ly/2BWCfd

re: Upcoming C# 3 Guidance From Microsoft

Lijo — Wed, 04 Nov 2009 13:47:37 GMT

Hi,

Could you please let me know whether there is any C# 3 book available that explains about how to implement SOLID principles (Open Closed Principle,DI,Likosov, etc) using language features like GENERICS, LINQ, Lambda Expression,etc.

--Sorry if it is a wrong place to ask this question as this is a deviation from the topic.

Thanks

Lijo Cheeran Joseph

re: "Object is currently in use elsewhere" error.

PeterRitchie — Tue, 20 Oct 2009 21:16:44 GMT

@AlanB: GDI+ (the underlying Windows library that Graphics uses) is not thread safe. Adding a Sleep() call like that, as you've noticed, simply slows down your code and reduces the likelihood of having another exception because it simply re-tries that code that failed and it's less likely that another conflicting GDI+ call is being made at the very same time on another thread.

This isn't a solution. Since GDI+ isn't thread-safe you need to synchronize calls to GDI+ on multiple threads. This simply means having a shared lock object and using the C# lock keyword where ever you perform GDI+ operations (i.e. around acquisition of a resource and disposal of the resource).

Since you code isn't the only code that can perform GDI+ operations you can't synchronize all GDI+ code like this. This leaves you to marshal the code back to the GUI thread--which is a drastic design change from what you've got now.

Long story short: you can't perform GDI+ operations reliably on any thread other than the main (GUI) thread.

"Object is currently in use elsewhere" a workaround

Alan8 — Tue, 20 Oct 2009 19:29:19 GMT

I've been getting this error since I moved some graphics code to a background thread.

Every Graphics.FromImage () had a matching Dispose () call, so that wasn't the problem.

It was happening in the Graphics.DrawImage () method. But only the first time.

So I put a try/catch block around the DrawImage () call, and a Thread.Sleep (5) in the catch block before trying the DrawImage () a second time. This worked. Sleep parameters <= 3 ms didn't work.

There's a noticeable pause when this happens, which suggests it's a Microsoft/.NET threading problem. Maybe it will go away in a later version of .NET.

re: Sudden "...you must have Terminal Server User Access permissions on this computer." Error.

Xaj007 — Mon, 19 Oct 2009 13:53:25 GMT

Big big Thanks!

re: Using Toolbox for Code Snippets in Visual Studio 2005

Serdar Osman Onur — Tue, 13 Oct 2009 00:15:28 GMT

nice feature, i was looking for this...

re: Thread.Sleep is a sign of a poorly designed program.

Jimbo — Fri, 09 Oct 2009 08:30:22 GMT

How would you handle email throttling in a windows service?

Thanks.

re: Windows Live Messenger Virus Scanner Settings

Xavier — Mon, 28 Sep 2009 09:33:04 GMT

And... what about the Eset Security? :)

re: Performance Implications of try/catch/finally

PeterRitchie — Thu, 24 Sep 2009 13:52:44 GMT

@bmm60: The point of the article *is* to show that using try/catch does impact performance. What you take out of the post, is up to you. How, otherwise, would you show that try/catch does affect performance if you don't show the analysis of two different snippets of code--that differ only by the addition of a try/catch?

It's true that the second can't be optimized the same as the first; but that's because of the added try/catch (or try/finally in C#).

Changing the code to what Norman suggests (i.e. comparing linear code to looping code with a try/catch) most certainly would be comparing apples to oranges. It would then be the very post you're saying it already is. It wouldn't tell you anything--you couldn't see the difference in optimizations of the same code with and without a container try/catch.

The code *could* use a catch block and push the WriteLine outside the try/catch; but, it would show the same thing without adding any clarity, IMO.

re: Performance Implications of try/catch/finally

bmm6o — Thu, 24 Sep 2009 05:00:50 GMT

> The point of the post is to dispel the conventional wisdom that using try/catch does not impact performance; this shows that it does.

I disagree. This article shows that changing the requirements of a program can result in an implementation that has different performance characteristics. Moving the WriteLine to the finally block means you're comparing apples to oranges; the programs aren't interchangeable implementations of the same spec, one using try/finally and the other not, they implement different specifications.

I mean, it's true that the second program can't be optimized in the same way that the first one can. I think it's invalid to draw general conclusions about that from this example. What if you rewrite it in the style Norman suggests?

re: Performance Implications of try/catch/finally

Chuck — Tue, 22 Sep 2009 05:39:24 GMT

Thanks for appropriately reading thru the typos in my post :)

On further review, I see all that should've been clear, but I thank you also for accommodating me in my paraphrase of your point.

re: Performance Implications of try/catch/finally

PeterRitchie — Sun, 20 Sep 2009 17:14:35 GMT

@Chuck. That's the point; the mere introduction of a try block now means there are three explicit potential outcomes. Previously they where only implicit and could be optimized away because they were implicit. The only difference between the two snippets of code is the try/catch. Thus, "using try/catch does not affect performance" is not true (the point of the post).

re: Performance Implications of try/catch/finally

PeterRitchie — Sun, 20 Sep 2009 17:12:04 GMT

@foobar,that's kind of the point. How do you show how using try/catch affects performance if you don't have "two programs"?

re: Performance Implications of try/catch/finally

Chuck — Sat, 19 Sep 2009 23:28:32 GMT

If I can summarize, I think the criticisms between your non-try code and your try-blocked code is that they're not really functional equivalents. I'm a linguist, not a computer-scientists so I apologize if the jargon is off -- but in the non-try code, the value of the variable inside WriteLine is always 3 regardless of what happens with the other functions being called.

The JIT-compiled code is -- absolutely and of course -- different between the two because the try-blocked code has not one but THREE potential outcomes:

int count = 1;

try

{

SomeMethod(); ## Raise exception here count=1

count++;

SomeOtherMethod(); ## Raise exception here count=3

count++;

}

The functionally-equivalent code, then, is not something that runs two functions and makes count == 3, but rather, the possibility of a raised exception means that there are two implicit conditionals within the try block where there are not within the non-try-block'd code.

So in order to instantiate the conditionals implied within the try block due to the raised exception, you'd have to do something like:

int count = 1;

if someMethod(){

count++

if someOtherMethod(){

count++}

}

Console.WriteLine(count);

I guess I'd be curious to know: is there a performance difference between THAT and the try-finally code?

re: Performance Implications of try/catch/finally

foobar — Sat, 19 Sep 2009 20:54:36 GMT

@Peter The examples are two different programs. They have different outputs depending on when an exception is thrown. They are not the same and thus the optimizations are not the same. If you wanted to point out that similar programs with different output might have different runtime performance, then keep the article. But, it does not prove anything about the lack of optimizations in a try/catch/finally block.

re: Performance Implications of try/catch/finally

PeterRitchie — Sat, 19 Sep 2009 19:50:54 GMT

@Jonathan Allen: In what way do you think this is nonsense?

re: Performance Implications of try/catch/finally

PeterRitchie — Sat, 19 Sep 2009 19:50:32 GMT

@d * @bmm60 Exactly, we don't want it to optimise this code. The point of the post is to dispel the conventional wisdom that using try/catch does not impact performance; this shows that it does.