Nativ thread

Question

Hi,
Using the version solaris 8 java 1.2.2 , the threads are native so not
controlled by the user. Having 2 threads wich interfere each others because they share the same data, i have a critical section. How can i protect my data ? Is there semaphore in Java ? Any idea ?
Thanks in advance...
Olivier

Answer 1

Not sure I understand exactly your question but I will offer some tips.
First make sure all the native threads are attached to the VM, so they can all make use of the Java methods.
There is no semaphore built-in to Java. You can implement your own if you like, using synchronized methods of a class. A simple Semaphore class containing a private int to keep track of counting, and synchronized methods to increment, decrement, and optionally get and set the value of the counter, is sufficient for a simple semaphore. Synchronized anything is very slow in the 1.2 VM so if you are worried about performance, you are better off either upgrading to 1.4 or avoiding the Java synchronization operations.
If you are controlling access only to native resources, accessed only through native code, then you can use regular C++ thread operations. The Java thread calling the native methods will be safely controlled by the C++ threading functions, however you must not destroy a Java thread directly from native code. If you have a C++ thread you have created you can destroy it from your C++ code provided it is first detached from the VM. Of course, as with any native code, you must be very careful, because bugs in native code can cause truly bizarre VM behavior and thread problems are no different.
However, this approach will not work if you are working with a VM using a user-thread library, and it will not (necessarily) work if you are controlling access to a Java object which might be accessed both from native and from Java code. In this case, you must synchronize on the contested object using the JNI functions MonitorEnter and MonitorExit. C++ code between a MonitorEnter call and MonitorExit call will work exactly as if it were enclosed in a Java synchronized(){} block. You can call MonitorEnter and MonitorExit many times and on different objects, just as long as you call MonitorExit on each object as many times as you call MonitorEnter on it. Be aware of possible deadlock issues here, two threads can deadlock each trying to acquire locks held by the other. It is good practice also to exit monitors in the reverse order from which they were entered, although I do not know if this is a hard restriction or not in any particular VM.
Let me know if this answers your question or not :}