Multi-threading in the .NET Framework

Multi-threading is fully supported in managed code under the .NET Framework.

If your application uses Windows forms, you can use the threading support. However if you are using COBOL in a ThreadPool, do not use the threading support. Instead, you should invoke COBOL using the multiple run units. See MicroFocus.COBOL.RuntimeServices.

Note the following with regard to multi-threading in managed code:

• If your application uses Windows forms, you can use the threading support. However you need to understand ThreadPools to do this. See the ThreadPool class in the .Net Framework Help. An alternative is to invoke COBOL using multiple run units. See MicroFocus.COBOL.RuntimeServices.
• The CBL_THREAD_SUSPEND and CBL_THREAD_RESUME routines are deprecated in managed code and their use is bound by Microsoft restrictions.
  CAUTION:

  For managed applications in the .NET Framework, the CBL_THREAD_SUSPEND and CBL_THREAD_RESUME routines are provided but are implemented using obsolete APIs (Thread.Suspend/Thread.Resume) and as such their use is bound by restrictions imposed by the .NET Framework.

  Microsoft mandates that you "do not use the System.Threading.Thread.Suspend and System.Threading.Thread.Resume methods to synchronize the activities of threads. You have no way of knowing what code a thread is executing when you suspend it. If you suspend a thread while it holds locks during a security permission evaluation, other threads in the System.AppDomain might be blocked. If you suspend a thread while it is executing a class constructor, other threads in the System.AppDomain that attempt to use that class are blocked. Deadlocks can occur very easily."

  You can use the Compiler directive WARNINGS(2) to issue warnings when suspend and resume are being used.

• cobthreadtidy(), cobtidy(), and cobexit() routines are are deprecated in managed code. Their work is done automatically.