This workaround is not trivial and can cause deadlocks if not carefully programmed. Do this only if absolutely unavoidable.
If you try to run a multithreaded Java application that also uses native C/C++ code with previously-released libraries that have not been compiled with the -D_REENTRANT flag on, you could encounter problems, as explained here.
With a native-threaded JVM such as 1.1, libc stores system call error code in a thread-specific errno. When an mt-unsafe library references errno, it references the global version, because it was not compiled with the -D_REENTRANT flag on. Therefore, the library can't access the thread-specific errno and its errno-dependent response to a failed system call would be incorrect.
The real solution is to ensure that an MT Java application that also uses native code by way of native methods is linked with MT-safe (or at least errno--safe libraries).
However, if you cannot avoid referencing errno-unsafe libraries, the following workaround can help: Enable the main thread to enter the Java application and arrange for all calls to the unsafe library to be routed through the main thread. For example, if a thread makes a JNI call, the JVM can marshal all JNI arguments and put them in a queue serviced by the main thread. The thread can wait for the main thread to issue the call and return the results to it.
It is not necessary for calls made from only the main thread to the unsafe library to go through a lock, since calls to the library are single-threaded through the library; only the main thread ever calls the library. The main thread could issue non-blocking calls, and so forth, to ensure some amount of concurrency. The main thread's errno is global, and the same errno would be referenced by both libc and the MT-unsafe library.