MonitorEnter - happens-before?

Hello,

Does JNI's MonitorEnter/MonitorExit guarantee a happens-before

relationship on native side memory like "synchronized" does on Java

side ( http://java.sun.com/docs/books/tutorial/essential/concurrency/syncmet...

)? I.e. obviously it should provide happens-before for any Java

Objects that get manipulated on the native side, but does it provide

happens-before for native objects that get manipulated?

For example:

some C++ object has a member variable named obj and two JNI methods:

jniMethod1 and jniMethod2

Starting state: obj->getValue() would return 0

Java Thread 1 calls jniMethod1 which looks like:

MonitorEnter

obj->setValue(3)

MonitorExit

Java Thread 2 calls jniMethod2 which looks like:

MonitorEnter

print obj->getValue()

MonitorExit

Assuming that Thread 1 calls MonitorEnter first and no other calls are

made to obj->setValue() , can I be certain that 3 will always be

printed (as opposed to 0)?

Thanks!

[1071 byte] By [ThreadAskera] at [2007-11-27 2:11:44]
# 1

Well I guess the question is what makes you think it wouldn't?

It certainly sounds to me like it would work as you'd expect, not advancing past the second MonitorEnter until the first MonitorExit:

"The Monitor-Enter operation takes a jobject as an argument and blocks if another thread has already entered the monitor associated with the jobject." (http://java.sun.com/docs/books/jni/html/other.html)

Not that I really have any idea ;)

kindofbluea at 2007-7-12 2:05:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...
# 2

Well, I wonder because a synchronized block in Java guarantees two conditions:

no interleaving of code within blocks of code synchronized on the same object

happens-before for other synchronized blocks

http://java.sun.com/docs/books/tutorial/essential/concurrency/syncmeth.html

The link you gave (and my JNI book) only mentions the first, not the second.

ThreadAskera at 2007-7-12 2:05:14 > top of Java-index,Java HotSpot Virtual Machine,Specifications...