Multi Threading

[BaussHacker]

I know it's not Conquer related like that, but Multi Threading is a very big part, when developing Conquer PServers.

Originally Posted by Consider the following guidelines when using multiple threads:

Don't use Thread.Abort to terminate other threads. Calling Abort on another thread is akin to throwing an exception on that thread, without knowing what point that thread has reached in its processing.

Don't use Thread.Suspend and Thread.Resume to synchronize the activities of multiple threads. Do use Mutex, ManualResetEvent, AutoResetEvent, and Monitor.

Don't control the execution of worker threads from your main program (using events, for example). Instead, design your program so that worker threads are responsible for waiting until work is available, executing it, and notifying other parts of your program when finished. If your worker threads do not block, consider using thread pool threads. Monitor.PulseAll is useful in situations where worker threads block.

Don't use types as lock objects. That is, avoid code such as lock(typeof(X)) in C# or SyncLock(GetType(X)) in Visual Basic, or the use of Monitor.Enter with Type objects. For a given type, there is only one instance of System.Type per application domain. If the type you take a lock on is public, code other than your own can take locks on it, leading to deadlocks. For additional issues, see Reliability Best Practices.

Use caution when locking on instances, for example lock(this) in C# or SyncLock(Me) in Visual Basic. If other code in your application, external to the type, takes a lock on the object, deadlocks could occur.

Do ensure that a thread that has entered a monitor always leaves that monitor, even if an exception occurs while the thread is in the monitor. The C# lock statement and the Visual Basic SyncLock statement provide this behavior automatically, employing a finally block to ensure that Monitor.Exit is called. If you cannot ensure that Exit will be called, consider changing your design to use Mutex. A mutex is automatically released when the thread that currently owns it terminates.

Do use multiple threads for tasks that require different resources, and avoid assigning multiple threads to a single resource. For example, any task involving I/O benefits from having its own thread, because that thread will block during I/O operations and thus allow other threads to execute. User input is another resource that benefits from a dedicated thread. On a single-processor computer, a task that involves intensive computation coexists with user input and with tasks that involve I/O, but multiple computation-intensive tasks contend with each other.

Consider using methods of the Interlocked class for simple state changes, instead of using the lock statement (SyncLock in Visual Basic). The lock statement is a good general-purpose tool, but the Interlocked class provides better performance for updates that must be atomic. Internally, it executes a single lock prefix if there is no contention. In code reviews, watch for code like that shown in the following examples. In the first example, a state variable is incremented:

Source:

[Spirited]

I would just use the Async Socket system that I released in Project Kanji and make a multithreaded queue that makes use of Pulsing.

[BaussHacker]

Originally Posted by Fаng

I would just use the Async Socket system that I released in Project Kanji and make a multithreaded queue that makes use of Pulsing.

And I would use what's recommended.

[GRASSHOPPA]

I've been getting pretty interested in threading lately..so of course I need to ask

whats the difference between multi threading and thread pools?
multi threading seems to do the same thing as a thread pool with its queuing and such..yes I'm going to google it later..just curious what people like about one over the other

[Korvacs]

Threadpools are a form of multi-threading, but in the simplest terms having the program using more than 1 thread is multi-threading instead of a single threaded application design.

But more generally speaking if you have a big 'task' to complete in the application using 1 thread for every logical core that the processor has, and then spreading the load would be the best way to achieve multi-threading.

[GRASSHOPPA]

that makes a bit more sense
Do threadpools use each logical core?if not what does?

[Korvacs]

Originally Posted by GRASSHOPPA

that makes a bit more sense
Do threadpools use each logical core?if not what does?

No, the default threadpool size for .net is 25, it can use as many as 200 i think the limit is (Google this to confirm), the idea of using the .net threadpool is to create a work task and send it to the threadpool. So its not meant to use as a part of the core application threading.

Everytime you create a thread it just gets dumped onto a pile of threads which are distributed by the kernel i think? Dont know specifics about thread distribution across a processor.