none
Use of threding in Application. RRS feed

  • Question

  • HI,

    Which is the better way to use Threading in Application.

    Use a thread in DLL or Application that consumes that Dll.

    Please provide me best approaches.

    Wednesday, May 23, 2012 2:03 PM

Answers

  • Hi bjshah1,

    I found some very good points during my net surf. Please check out these:

    • 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 MutexManualResetEventAutoResetEvent, andMonitor.

    • 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 ofMonitor.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# lockstatement 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.

      • Avoid the need for synchronization, if possible. This is especially true for heavily used code. For example, an algorithm might be adjusted to tolerate a race condition rather than eliminate it. Unnecessary synchronization decreases performance and creates the possibility of deadlocks and race conditions.

      • Make static data (Shared in Visual Basic) thread safe by default.

      • Do not make instance data thread safe by default. Adding locks to create thread-safe code decreases performance, increases lock contention, and creates the possibility for deadlocks to occur. In common application models, only one thread at a time executes user code, which minimizes the need for thread safety. For this reason, the .NET Framework class libraries are not thread safe by default.

      • Avoid providing static methods that alter static state. In common server scenarios, static state is shared across requests, which means multiple threads can execute that code at the same time. This opens up the possibility of threading bugs. Consider using a design pattern that encapsulates data into instances that are not shared across requests. Furthermore, if static data are synchronized, calls between static methods that alter state can result in deadlocks or redundant synchronization, adversely affecting performance.


    Regards, http://shwetamannjain.blogspot.com or https://shwetalodha.wordpress.com/

    Wednesday, May 23, 2012 2:38 PM
  • Hi, 

    We will suggest better approach if you provide more information what you trying to do.

    meanwhile please look into Managed Threading Best Practices


    If this post answers your question, please click "Mark As Answer". If this post is helpful please click "Mark as Helpful".

    Wednesday, May 23, 2012 2:44 PM
  • You must be thinking about something specific, because in general, this question is pointless.

    Any time you call a function, you are passing control of the calling thread to that function.  Calling functions is OK, so obviously it's OK to create DLL functions where the calling thread is owned by the application.  It's fundamentally necessary.

    Some functions create their own threads or use thread pools.  Any asynchronous function like a Socket.BeginRead will make use of this pattern.  So obviously its OK to have threads be owned by a DLL too.

    "Best approach" means, choose what is appropriate to your needs.  You have to divulge your needs.

    Wednesday, May 23, 2012 2:59 PM

All replies

  • Hi bjshah1,

    I found some very good points during my net surf. Please check out these:

    • 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 MutexManualResetEventAutoResetEvent, andMonitor.

    • 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 ofMonitor.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# lockstatement 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.

      • Avoid the need for synchronization, if possible. This is especially true for heavily used code. For example, an algorithm might be adjusted to tolerate a race condition rather than eliminate it. Unnecessary synchronization decreases performance and creates the possibility of deadlocks and race conditions.

      • Make static data (Shared in Visual Basic) thread safe by default.

      • Do not make instance data thread safe by default. Adding locks to create thread-safe code decreases performance, increases lock contention, and creates the possibility for deadlocks to occur. In common application models, only one thread at a time executes user code, which minimizes the need for thread safety. For this reason, the .NET Framework class libraries are not thread safe by default.

      • Avoid providing static methods that alter static state. In common server scenarios, static state is shared across requests, which means multiple threads can execute that code at the same time. This opens up the possibility of threading bugs. Consider using a design pattern that encapsulates data into instances that are not shared across requests. Furthermore, if static data are synchronized, calls between static methods that alter state can result in deadlocks or redundant synchronization, adversely affecting performance.


    Regards, http://shwetamannjain.blogspot.com or https://shwetalodha.wordpress.com/

    Wednesday, May 23, 2012 2:38 PM
  • Hi, 

    We will suggest better approach if you provide more information what you trying to do.

    meanwhile please look into Managed Threading Best Practices


    If this post answers your question, please click "Mark As Answer". If this post is helpful please click "Mark as Helpful".

    Wednesday, May 23, 2012 2:44 PM
  • You must be thinking about something specific, because in general, this question is pointless.

    Any time you call a function, you are passing control of the calling thread to that function.  Calling functions is OK, so obviously it's OK to create DLL functions where the calling thread is owned by the application.  It's fundamentally necessary.

    Some functions create their own threads or use thread pools.  Any asynchronous function like a Socket.BeginRead will make use of this pattern.  So obviously its OK to have threads be owned by a DLL too.

    "Best approach" means, choose what is appropriate to your needs.  You have to divulge your needs.

    Wednesday, May 23, 2012 2:59 PM