Cancel VS Error Messages? And a Threading Question <vb.net>

[NeuralJack]

I'm basically stress-testing this program I'm writing. I'm running commands extremely quickly and handling exceptions as they come up. The problem is that i've noticed the VS error messages , themselves, really take a chunk out of your processing time.. so i'm wondering if there's a way to make the error message not appear on the Immediate window.

I could just build it and run it out of visual studio but I'm looking for a trick I can use often. I dont really want to have to build it and run it out of the studio too often.
----
I guess this brings me to another generalized question. The program i'm making has many routines that run simultaneously on as many threads as the user wants. But some of the things that the user can do on those threads shouldnt be done simulaneously.. so I made a Queueing class. If a routine encounters a command that needs queueing it throws that routine into an indefinite thread.sleep until the the routine that is running is complete.

When the running routine is complete it removes itself from the queue and INTERRUPTS the next routines thread.sleep thread therefore allowing that next routine to continue working.

The problem arises with all the Thread INTERRUPTS because they throw exceptions. If stress testing, there can be TONS of exceptions, which is what i expect BUT the error messages themselves on Visual Studio really slow things down. But My other general questions are this: Does anyone have a problem with Interrupting/Aborting threads like mad? Does it sound dangerous? In some cases a user may interrupt 500-1000 threads per second, depending on what they're doing.

There may be a better way to Queue my routines but this way was sounding pretty smooth to me. I can think of other ways to Queue my routines and i'll be testing them too.

 

[IngisKahn]

Stress testing through the debugger? That doesn't sound right.
Also exceptions are generally a bad thing. Why are you throwing so many?

Calling Sleep is always a bad thing.
Calling Thread.Abort from another thread is always a bad thing.
Use the provided thread syncronization objects.

 

[snarfblam]

This sounds like a recipie for race-conditions, hangs, and crashes. I strongly recommend you read a tutorial on thread-syncronizing.

 

[NeuralJack]

Thanks for the Information guys.

I'll look into the thread synconizing. At least I've been keeping track of my threads through collections so they wont get out of hand number-wise.

The reason I was using aborts and interrupts is because I wanted an immediate response time when the thread is restarted. Putting something in a pause While loop that checks for an 'unpause' condition now and then just didnt seem so great to me.

But the consensus so far seems to be that you should try to have as few exceptions as possible - even if you do properly handle them. So I'll look for anohter way to do this stuff.

There are many things in .Net that I just dont know about yet, like these thread syncronizing tools. But usually all i need is someone to give me a new word to look up and it opens up a whole new area of programming for me that helps a ton. There are so many functions and classes that .Net has in it I often wonder if i'm doing things the -best- way. I suppose I should read more articles or something.

 

[MrPaul]

Threading and locking

Putting something in a pause While loop that checks for an 'unpause' condition now and then just didnt seem so great to me.

Use the provided thread syncronization objects.

System.Threading.AutoResetEvent
System.Threading.ManualResetEvent
System.Threading.Semaphore

These handle all the suspending/resuming for you.

However....

If a routine encounters a command that needs queueing it throws that routine into an indefinite thread.sleep until the the routine that is running is complete.

It sounds like the lock (C#) and SyncLock (VB) control flow blocks might help here. They are used to define a section of code that only one thread may enter at a time.

Good luck

 

[NeuralJack]

Ah thanks Mr. Paul. I have been using synclock.. anohter great tip i got from here long ago. but these are new to me:

System.Threading.AutoResetEvent
System.Threading.ManualResetEvent
System.Threading.Semaphore

 

[MrPaul]

Events and semaphores

Events are a basic thread synchronization primitive. They can be in the set or unset state. One or more threads can wait for an event to become set. The process of suspending the threads and resuming them when the event becomes set is handled by the framework. Another thread can release waiting threads by calling Set on the event. In the case of the AutoResetEvent, if there are threads waiting, one thread is resumed and the event immediately reverts back to the unset state. If there are none waiting, it remains in the set state until one is waiting, and then resets. In the case of the ManualResetEvent, the event remains in the set state until the Reset method is called. While the event is set, any attempt to wait on it will immediately succeed without causing the thread to block.

Basically they are like traffic lights. The AutoResetEvent only allows one thread to pass at a time before going back to 'red'. The ManualResetEvent remains on 'green' until told otherwise. I tend to find the auto-reset version much more useful.

Semaphores are similar except rather than simply being set or unset, they have a count. You initialize this count when you create the semaphore, and threads can 'acquire' it which decreases the count. If the count reaches zero, any threads that attempt to acquire it will block until the count is increased by another thread releasing the semaphore.

The other main synchronization primitive is the Mutex, but this is really only necessary when dealing with cross-process synchronization.

All primitives provided by the framework should ensure safety, fairness, and progression.

Good luck

 

[NeuralJack]

Thanks guys. A few more questions. I found this article (http://www.devcity.net/Articles/160/3/article.aspx) at a site, so I'm read up on many syncronization techniques. Monitor or AutoResetEvent seem the way to go. I'm only concerned about this quote :
'You do not know the order of threads for each signal either. If multiple threads are waiting on an object, you are only guaranteed that one will get in per Set when a wait method is called. '

I think, for me, it's important that the threads execute in order of request. If there is anything that will call the next thread in the order they requested permission, let me know. Otherwise I suppose i'll have to make something that keeps track of the order that they requested permission to the object.

The other question is that someone above mentioned I should never use thread.sleep or thread.abort. Well, what if i want to sleep for 10sec? And what if i want to interrupt that sleep in some conditions? How can I do it if I dont do it with thread.sleep and thread.interrupt/thread.abort?

 

[MrPaul]

Sleep/Abort to WaitOne/Set

The other question is that someone above mentioned I should never use thread.sleep or thread.abort. Well, what if i want to sleep for 10sec? And what if i want to interrupt that sleep in some conditions? How can I do it if I dont do it with thread.sleep and thread.interrupt/thread.abort?

When a thread waits on a wait object such as AutoResetEvent etc, a timeout value can be provided, which specifies the maximum amount of time to wait. If the event has not become set in this time, the thread is resumed and the method returns false. If the event does become set while the thread is waiting, the thread is resumed and the method returns true.

Therefore, Sleep calls can be replaced by calls to WaitOne on a synchronization primitive (or WaitAny if there may be multiple conditions), and Abort calls can be replaced by the appropriate call on the primitive, such as Set on an event.

Good luck

 

[NeuralJack]

Excellent

Excellent, that's smooth stuff. It's working great. The funny thing is however how many times you see people using thread.sleep. Even Microsoft uses it in coding examples. You're right though.. this is 100x more safe.

So, here is how I'd put a thread to sleep while allowing for aborting that sleep by another thread.

Public Class MyClass
     
     Public Sleeping as New AutoResetEvent(False)
     Public ContinueRunMe as Boolean = True

     Public Sub RunMe()
          If ContinueRunMe = True
               'Do some stuff
               'Then let's pause for a minute
               Dim Time as integer = 60000
               Sleeping.Reset()
               Sleeping.WaitOne(Time, False)
          End If
               If ContinueRunMe = True
               'Do some more stuff
          End If
     End Sub


     Public Sub AbortRunMe()
          ContinueRunMe = False
          Sleeping.Set()
     End Sub

End Class

 

[NeuralJack]

Just one more question

- Does anyone know of a thread syncronzier that will pass threads through in the order that they started to wait? I dabbled with making a class that would do it but it seems hard to avoid race conditions when using a generic List to keep track of them.

 

[IngisKahn]

3 things:

Add stateful objects to your queue, not threads.

Use lock/SyncLock to avoid race conditions

Consider using a thread pool if you have more threads than cores or number of threads waiting on IO.