If you have a flag, why do you still need to call abort or suspend?
My assumption was that you would set the flag on the threads that need to be
aborted, and only on these threads.
Then, the threads that don't have the flag set should continue running, they
don't need to be suspended.
And the threads that have the flag set should terminate by testing the flag.
You should test the flag in your loops (my assumption was that you only had
one main loop in every thread but you code may be a bit more complex) and
the thread will terminate. The only difficulty here is terminating threads
that may be waiting for input and thus won't test the flag until they
receive new input. My suggestion to use asynch read was a way to handle this
case.
Calling abort will not wait for locks to be released (may never happen), but
it will release all the locks by propagating a special exception. So, you
are ok here.
It seems to me that you are using a strange strategy to handle concurrent
access on a shared resource (your config data). Instead of protecting the
shared resource with monitors (using the C# lock keyword to synchronize the
methods that access the config data), you are interrupting all threads when
you need to modify the shared data, and you are resuming them after the
shared data has been modified. Your approach has several **major** problems:
* Performance: stopping and resuming all threads costs a lot more than
acquiring a monitor. Also, you interrupt everything everytime you need to
modify the shared data. If you used the monitor strategy instead, the other
threads will be able to continue while the config is being modified, at
least as long as they don't try to read the config (they they will block on
the monitor until the modification is complete).
* Correctness of your logic and risks of deadlock. The threads will get
suspended and resumed at random points in their execution. If the config is
stored in a hash table and if the threads use hash table lookup logic to
retrieve it, you run the risk of interrupting a thread in the middle of the
lookup operation. For example, the thread may have computed the bucket index
but may not have obtained the bucket itself. If the main thread interrupts
at this specific point and triggers a rehash of the table, the thread that
does the lookup will do unpredictable things when it gets resumed (because
the hash table will contain a different bucket at the index that was
computed before the interruption).
And, things are even worse if you synchronize the hash table. In this case,
the thread that does the lookup will acquire the monitor on the hash table
to do the lookup. Then the main thread will suspend it in the middle of the
lookup. And then the main thread will try to modify the hash table and will
block forever because the table's monitor is acquired by a thread that is
suspended (suspending a thread does not release the monitors that it owns).
Your server will be dead!
So, the answer to your last question is: Yes, you will be in serious trouble
if you use this strategy and if you share a hashtable between your main
thread and the socket thread.
So, I strongly encourage your to avoid suspend and abort and to code
everything with monitors.
Bruno
"Keith Langer" <ta******@aol.com> a écrit dans le message de
news:O5**************@TK2MSFTNGP10.phx.gbl...
Thanks guys. I took the approach of setting a flag from the main thread
which directs the socket thread to abort or suspend. Now the socket
thread handles these actions when it is safe to do so.
According to MSDN, the Abort method only executes when it is safe, so
I'm guessing that at the very least it waits until all locks are
released. Is this not the case? After testing it, I found that the
abort did take a few seconds.
One more question - if the main thread can read or write to a hashtable
and the socket thread reads from that hashtable, is there any danger of
an incomplete write operation while the socket thread is accessing an
item by its key? I am not using enumeration.
thanks,
Keith
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!