usleep block other thread

I have review the document for C$SOCKET.  documentation.microfocus.com/.../BKPPPPLIBRS089.html

It mention:  

Note: If a COBOL thread calls one of these operations, all threads are blocked until the operation is finished and control is returned to the COBOL program.

I am wondering whether the COBOL thread is native implementation under OS(for example: Unix pthread)

Otherwise, why C$SOCKET would block other threads.

The behavior is same as I call C usleep.

extend COBOL does not use OS facilitities for threading, but instead uses a runtime implementation of threading.  That is, the runtime switches between the various threads defined in an extend COBOL program.  Here's some information from the ACUCOBOL-GT User's Guide:

6.8.7 Multithreading and Multiprocessor Systems

ACUCOBOL-GT implements multithreading in a machine-independent fashion. It neither needs nor uses any multithreading capabilities of the host system. This has several advantages:

   You can run multithreaded programs in environments that do not otherwise support multithreading.

   Multithreaded programs run the same way under different environments.

   ACUCOBOL-GT can provide features not universally available in multithreaded systems, such as the link between windows and threads.

There are, however, a few disadvantages to this implementation. Chief among these is that the operating system is not aware that there are multiple threads running in the runtime's process. This is primarily an issue on systems that have multiple processors. Some of these systems can allocate additional processors to a task if they know that the task contains more than one thread--up to one processor per thread. But because these systems do not see the runtime as a multithreaded entity, multiprocessor allocation does not happen.

Typically, multiprocessor systems are used to provide support for more users. By having more processors in the system, the system can run more processes at once, and in this way increase the number of users the machine can effectively support. But the system will not increase performance for a single process (assuming that the process gets 100% of the CPU's time--an unrealistic assumption in a production environment). In practice, a multiprocessor machine will usually not benchmark any better than a single processor machine for single-task benchmarks, but they will provide much better total throughput in a multi-user production environment.

In summary, multithreading an ACUCOBOL-GT program will not affect its performance in any special way on a multiprocessor machine. Any gain, or loss, will be the same as for a single processor system.

extend COBOL does not use OS facilitities for threading, but instead uses a runtime implementation of threading.  That is, the runtime switches between the various threads defined in an extend COBOL program.  Here's some information from the ACUCOBOL-GT User's Guide:

6.8.7 Multithreading and Multiprocessor Systems

ACUCOBOL-GT implements multithreading in a machine-independent fashion. It neither needs nor uses any multithreading capabilities of the host system. This has several advantages:

   You can run multithreaded programs in environments that do not otherwise support multithreading.

   Multithreaded programs run the same way under different environments.

   ACUCOBOL-GT can provide features not universally available in multithreaded systems, such as the link between windows and threads.

There are, however, a few disadvantages to this implementation. Chief among these is that the operating system is not aware that there are multiple threads running in the runtime's process. This is primarily an issue on systems that have multiple processors. Some of these systems can allocate additional processors to a task if they know that the task contains more than one thread--up to one processor per thread. But because these systems do not see the runtime as a multithreaded entity, multiprocessor allocation does not happen.

Typically, multiprocessor systems are used to provide support for more users. By having more processors in the system, the system can run more processes at once, and in this way increase the number of users the machine can effectively support. But the system will not increase performance for a single process (assuming that the process gets 100% of the CPU's time--an unrealistic assumption in a production environment). In practice, a multiprocessor machine will usually not benchmark any better than a single processor machine for single-task benchmarks, but they will provide much better total throughput in a multi-user production environment.

In summary, multithreading an ACUCOBOL-GT program will not affect its performance in any special way on a multiprocessor machine. Any gain, or loss, will be the same as for a single processor system.

Thanks for the prompt attention.

In other words,

When COBOL call C function which run for a long time,

the COBOL THREAD would be suspended.

Because COBOL runtime is single process/thread in OS  level.

If the C function is a long-running process,

the better practice :

Make the C function to create its own thread for its own process

and return to COBOL ASAP.

That is correct.