Limits on number of Locks/Monitors (a.k.a. java.lang.Object)  
Index ‹ java-programmer
Author Message
mehlitkim
PostPosted: 2003-10-8 6:30:00 Top
java-programmer, Limits on number of Locks/Monitors (a.k.a. java.lang.Object) Hi all,

I know that under Unix/Linux, there is a max number of
synchronization objects (e.g. semaphores etc.) that one
can create.

I assume that likewise, there is a max number of mutexes
and conditional vars that one can create in a threading
environment such as when using Pthreads under Solaris.

Now, each java Object provides the Monitor functionality,
and I can easily create several thousand java.lang.Object(s)
in the JVM given sufficient memory.

Given the above, it seems that I can easily create more
synchronization objects (java objects) than the underlying
threading system supports in Java/JVM.

Is this true ? If so, how does Java/JVM manage to accomplish this ?

Please, someone drop me a clue!

Thanks,
/Meh
 
Chris Uppal
PostPosted: 2003-10-8 15:46:00 Top
java-programmer >> Limits on number of Locks/Monitors (a.k.a. java.lang.Object) Meh-Lit Kim wrote:

> Given the above, it seems that I can easily create more
> synchronization objects (java objects) than the underlying
> threading system supports in Java/JVM.

Some techniques that could be used.

Have an isLocked flag in the header of each object. Have a *single*
system-wide OS-level mutex. Test, set and release the isLocked flags of all
objects under the control of that OS mutex. You'd need to set up your own
waiting queue(s) too, but that's just code...

Generalise the above to have a pool of such mutexes (and queues). Chose a
mutex for any object by -- say -- using the identityHash() of the object.
This allows less contention in that each OS mutex is shared amongst fewer
objects. I think early Sun JVMs did this.

Another technique is to use "thin locks" (I first saw the term used by the IBM
JVM people, I don't know if they invented it). This uses a few bits in the
object header. In normal circumstances when an object is locked there is no
need for a real Mutex because no other thread is going to access it anyway
(think of all the serialized methods of StringBuffer that get used by "adding"
strings, for instance). So in the easy case "locking" an object is just a
test-and-set of a flag with a machine-specific instruction sequence that is
thread-safe but does not involve expensive OS facilities. When a thread takes
out a lock, if it finds that the lock is already by a different thread, then it
"inflates" (again this is the word used by the IBM people) the lock into a real
OS-level mutex (a "fat lock") and all *subsequent* synchronisation on that
object will use the real mutex. Thus most synchronisation takes a fast path
that is quick and light on OS resources. I think that both Sun and IBM (and
probably others too) use this technique these days. See the literature from
IBM
and Sun for more (and more correct) details.

Of course these techniques could be combined.

No doubt there are other techniques. E.g. the JVM implementation of threads
may
be such that there is no need for OS-level mutexes at all.

-- chris



 
 
Index ‹ java-programmer