|
There is one case in which I have used it where it is actually useful to slow things down for the user.
The case in point is an update to an application - sometimes the update is so small that all the user would see is a number of dialogues and progress bars flashing on the screen leaving them to wonder if the update has taken place.
So I introduced a four second sleep in order to allow the user to see that something was happening.
It has saved me from having to say "yes the update did take place, it was just very small" - that comfortable warm feeling is very important to the user.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Or something like this:
public class Utility
{
private static readonly object SyncLock = new object();
public void WaitForTime(int milliseconds)
{
lock (SyncLock)
{
Monitor.Wait(SyncLock, milliseconds);
}
}
public WakeAllThreads()
{
lock (SyncLock)
{
Monitor.PulseAll(SyncLock);
}
}
}
|
|
|
|
|
Thanks Pete! Much appreciated 
I shall now use that method - it would be nice if Microsoft deprecated the sleep method so that people like me were prevented from using it.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
why the appreciation? It's more code than a simple while loop with a Sleep.
why you want be thankful when there really isn't a justification for it?
M$ probably deprecate Thread.Sleep either because its syntax laywer told him so or simply it isn't "cool"
dev
|
|
|
|
|
devvvy wrote: why the appreciation? It's more code than a simple while loop with a Sleep.
So, you think he has to write this out every time? Chuck it in a library and you're done - a simple
new Utility().WaitForTime(5000);
|
|
|
|
|
Peter - this is nice/good idea. But this detracts the discussion to get to the bottom:
SCENARIO 1/3 is just plain stupid to use Thread.Sleep - so just forget it.
SCENARIO 2 - there's yet one single real justification to establish "Thread.Sleep" is *Evil*
(as i pointed out in very beginning timer+event handler *can* be alternative - but why bother)
dev
|
|
|
|
|
devvvy wrote: But this detracts the discussion to get to the bottom
No it doesn't. It shows alternatives. The reason people are using the term "Evil" (and I think this is the word you're getting hung up on) is because threading isn't easy. It isn't trivial. But Thread.Sleep makes it appear as though it is because it's a convenience to hide the complexity, and sooner or later, this complexity creeps out and rips your face clean off. Subtle bugs creep in and they are hugely difficult to track down because they are timing based, and that timing is not predictable, because Thread.Sleep isn't predictable. The OS can actually do different things depending on what you've done with it.
|
|
|
|
|
Thanks Pete - I saw your argument on application exit.
Now I would conclude Thread.Sleep is evil for all SCENARIO 1,2,3
Big Thank you!
dev
|
|
|
|
|
devvvy wrote: why the appreciation? It's more code than a simple while loop with a Sleep.
why you want be thankful when there really isn't a justification for it?
Because someone, especially as it is a person I don't personally know, went out of their way to offer me help.
In my books that deserves my appreciation 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
right, but do you see the point on why you need replace Thread.Sleep for SCENARIO 2 with ten more lines of code (re-implement with Timer+Event handler)?
If no, your *thank you* will confuse other users for taking that really "Thread.Sleep" is evil, casting further confusion and un-necessary complication on this otherwise simple subject (You should thank those syntax lawyers for this).
That's how we never get to bottom of things
dev
|
|
|
|
|
Why is that better? Actually isn't that worse because when you call WakeAllThreads it will wait on the lock and your app will be unresponsive in all threads (including the one you're sending a wakeup call from)?
|
|
|
|
|
That's just a paste of some code I use to wake things up to kill all the threads (this is the scenario I talk about above). Monitor has a simple Pulse method as well to wake a single thread before the timeout expires.
|
|
|
|
|
there's still no justification to not just do a simple while+Thread.Sleep for SCENARIO 2 if the thread isn't an UI thread (Despite how uncool it has become to Thread.Sleep because syntax lawyers tell us so)
dev
|
|
|
|
|
Let's have the same discussion on;
GOTO
- On Error Resume Next
- GC.Collect
- Application.DoEvents
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Let's not 
|
|
|
|
|
why not? we're developers - i love tell others what's right (cool) and what wrong (evil)
dev
|
|
|
|
|
i have use this code and apply it microsoft visual studio 2012 which has its inbuilt sql server....in in this case how can i connect to the databas?
conn.ConnectionString = "Provider=SQLNCLI;Data Source=(LocalDB)\v11.0;AttachDbFilename=ozeki.mdf;Integrated Security=SSPI";
this the connection string which i have used...
and it appear an error message as follow
(login time out , an error has occured while establishing aconnection to the server.when connecting to sql server2005, this fauilure may be caused by the fact that under the default setting sql server dosn't allow remote connection. named pipe, could not open a connection to sql server)
modified 18-Feb-13 11:05am.
|
|
|
|
|
Member 9641406 wrote: AttachDbFilename=ozeki.mdf
Please make sure there is ozeki.mdf in current directory and you have read/write access to it (current directory may be project or bin depending on app type).
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
there is appear in server explorer the database ozeki.mdf which i have created in my application, but i couldn't make the correct connection to it ,,, i copy the connection string from ozeki.mdf property which contain the full path but it result the above error ,,,
|
|
|
|
|
Is it asp.net, desktop or metro application?
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
hi,
I dig around [^]understand that depending on compiler architecture using statement is actually a syntactic sugar ...
Translate FROM:
<br />
using (TransactionScope scope = new TransactionScope())<br />
{<br />
...<br />
}<br />
TO:
<br />
TransactionScope scope = new TransactionScope();<br />
#PT1#<br />
try {<br />
...<br />
#PT2#<br />
scope.Complete();<br />
#PT3#<br />
} finally {<br />
if (scope!= null)<br />
((IDisposable)scope).Dispose();<br />
}<br />
Previously, as I read, depending on compiler architecture code may blow up at #PT1# and thus finally cleanup block would never execute. But again, I read further that Microsoft already fixed this problem.
What I want to ask is, is using(TransactionScope) now Thread.Abort safe? If code blows up at #PT2# and not #PT3#, would "scope.Dispose" rollback the transaction as well?
Thanks
dev
|
|
|
|
|
At PT1 you haven't actually done anything with the scope, so even if it doesn't get cleaned up immediately, you haven't done anything which could damage your database.
What happens if it dies at PT2 is dependent on TransactionScope.Dispose, but I'd assume it does the right thing.
Thread.Abort is a blunt instrument, though, so it should only be used in extreme cases.
|
|
|
|
|
devvvy wrote: What I want to ask is, is using(TransactionScope) now Thread.Abort safe?
Not as far as I know (cannot test now), and shouldn't be. Terminating is exactly that - terminating. No cleanup, nothing gracefull, but an exit.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
No, you can't guarantee that the Dispose method will be reached with Thread.Abort - this applies to pretty much any disposable class wrapped with using, and is not specific to TransactionScope. To understand why this is the case, it's important to understand that Thread.Abort is triggered as an asynchronous exception (unlike most other exceptions which are synchronous). This means that there is no guarantee as to when the exception is raised.
As you've pointed out, the using pattern is effectively syntactic sugar for try/finally, and I'm a really big fan of it. Thread.Abort, however, tramples over this sandbox because of a nasty little timing issue. If your code is lucky enough to abort during the bit in the body of the using statement, then the finally part, and that's a fine thing. If, however, your code has just to say entered the finally portion and the abort exception is raised, the code will drop out of the finally block at the point that it encounters the exception - even if it hasn't called Dispose yet.
However, apart from forcing termination of the program, I have never seen a system that really needs a Thread.Abort as there are generally other, safer methods to cancel a thread. Use of Thread.Abort is generally recommended by people who aren't aware that there are issues with using it, as it is an easy method to implement.
modified 18-Feb-13 12:24pm.
|
|
|
|
|
Pete O'Hanlon wrote: If, however, your code has just to say entered the finally portion and the abort exception is raised, the code will drop out of the finally block at the point that it encounters the exception
Thanks very much Peter!
dev
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
