Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Limits on number of Locks/Monitors (a.k.a. java.lang.Object)

Reply
Thread Tools

Limits on number of Locks/Monitors (a.k.a. java.lang.Object)

 
 
Meh-Lit Kim
Guest
Posts: n/a
 
      10-07-2003
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
 
Reply With Quote
 
 
 
 
Chris Uppal
Guest
Posts: n/a
 
      10-08-2003
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



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RegularExpressionValidator that limits the number of characters that can be entered Nathan Sokalski ASP .Net 9 01-08-2007 06:36 AM
RegularExpressionValidator that limits the number of characters that can be entered Nathan Sokalski ASP .Net Web Controls 9 01-08-2007 06:36 AM
OT: Number Nine, Number Nine, Number Nine FrisbeeŽ MCSE 37 09-26-2005 04:06 PM
.NET limits a number of HTTP connections ildar ASP .Net Web Services 1 04-01-2005 02:11 PM
Limits on number of classes? John Hunter Python 2 06-13-2004 05:41 PM



Advertisments