|
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
|
|
|
|
|
Don't mention it. I'm glad to help, and this is the type of esoteric "how does it really work" question that I enjoy answering.
|
|
|
|
|
having the bomb dropped during entry to Finally block was something that I never seen in other articles (many of which full of half answers), do I am actually quite delighted that I can finally put this question to rest.
dev
|
|
|
|
|
Pete O'Hanlon wrote: I have never seen a system that really needs a Thread.Abort
Curious about that.
A windows service that is supposed to 'stop' will have difficultly actually doing that if normal threads continue to run. So something which doesn't have control over a child thread and which has already attempted to nicely stop the thread can use Abort to force the issue.
Is there an alternative?
|
|
|
|
|
It's down to the way you write your threading code. I tend to make a lot of use of Monitors to help with threading - the beauty of a Monitor is that you can pulse all of the monitor objects simultaneously, and let your thread code just check a simple volatile bool to determine whether or not the thread should stop at that point.
|
|
|
|
|
Pete O'Hanlon wrote: ...just check a simple volatile bool to determine whether or not the thread should
stop at that point.
Yes. That works well if you wrote the code. Or had a chance to review it at least.
If you didn't write the code, or made a mistake then the thread will continue to run.
And the service will also continue to run because until that thread stops the service will not stop. And the only recourse without Abort() is to use task manager to kill it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
