Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #22726 > unrolled thread

synchronized methods "under the hood"

Back to article view | Back to comp.lang.java.programmer

Contents

  synchronized methods "under the hood" bob smith <bob@coolfone.comze.com> - 2013-03-05 09:02 -0800
    Re: synchronized methods "under the hood" Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-03-05 09:15 -0800
    Re: synchronized methods "under the hood" Jan Burse <janburse@fastmail.fm> - 2013-03-05 18:59 +0100
      Re: synchronized methods "under the hood" Jan Burse <janburse@fastmail.fm> - 2013-03-05 19:16 +0100
      Re: synchronized methods "under the hood" Jan Burse <janburse@fastmail.fm> - 2013-03-06 15:24 +0100
    Re: synchronized methods "under the hood" Roedy Green <see_website@mindprod.com.invalid> - 2013-03-05 12:19 -0800
      Re: synchronized methods "under the hood" Sven Köhler <remove-sven.koehler@gmail.com> - 2013-03-05 23:44 +0100
        Re: synchronized methods "under the hood" Roedy Green <see_website@mindprod.com.invalid> - 2013-03-06 04:28 -0800
          Re: synchronized methods "under the hood" Jan Burse <janburse@fastmail.fm> - 2013-03-06 15:20 +0100

#22726 — synchronized methods "under the hood"

How do synchronized methods work "under the hood"?

Is there some kind of byte associated with each object that acts as a semaphore?

Thanks.

[toc] | [next] | [standalone]

#22727

On 3/5/13 9:02 AM, bob smith wrote:
> How do synchronized methods work "under the hood"?
>
> Is there some kind of byte associated with each object that acts as a semaphore?
There is an object monitor, which does indeed act as a mutex.  But there 
is more to it than that.  synchronized sections (which synchronize on 
the same monitor) create a happens-before relationship.  This includes 
any cache/memory coherency that needs to happen to give that.  It is 
likely implementation dependent on how all that works under the hood.

A good read is Java Concurrency in Practice by Brian Goetz.

<http://virtualinfinity.net/wordpress/technical-book-recommendations/java-concurrency-in-practice/>

It looks like the official site for the book is under 
construction.<http://jcip.net/>

[toc] | [prev] | [next] | [standalone]

#22728

bob smith schrieb:
> How do synchronized methods work "under the hood"?
>
> Is there some kind of byte associated with each object that acts as a semaphore?
>
> Thanks.
>

If I remember well the synchronized keyword is mapped to two things:

- In reflection it is mapped to the SYNCHRONIZED modifier:
 
http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/reflect/Modifier.html#SYNCHRONIZED

- In execution the invocation and return instruction is combined
   with a monitor enter and monitor exit.
 
http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.11.10

- For static methods the monitor is the class object, for non static
   methods the monitor is the instance object.
   http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6

Bye

[toc] | [prev] | [next] | [standalone]

#22729

Jan Burse schrieb:
> - For static methods the monitor is the class object, for non static
>    methods the monitor is the instance object.
> http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3.6

I am not sure whether any data, such as a byte, is used at all inside
an object to represent monitors. It could be also done externally,
and I guess it is up to JVM how to do it:

http://www.artima.com/insidejvm/ed2/

Bye

[toc] | [prev] | [next] | [standalone]

#22737

Jan Burse schrieb:
> - In execution the invocation and return instruction is combined
>    with a monitor enter and monitor exit.
>
> http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.11.10

Not sure whether also some code analysis is done,
and for private self calls of synchronized methods
from within synchronized methods, the monitor enter and
monitor exit is eliminated.

Bye

[toc] | [prev] | [next] | [standalone]

#22732

On Tue, 5 Mar 2013 09:02:25 -0800 (PST), bob smith
<bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
who said :

>How do synchronized methods work "under the hood"?
>
>Is there some kind of byte associated with each object that acts as a semaphore?

At the hardware level these are usually handled by some sort of test
and test instruction.  It tests if a byte is zero, and if it is, sets
it to 1.  It locks out any other CPU or thread from interfering
between the test and set.  If reports if the byte was zero to start
(in other words we successfully locked.) Test and Set is an "atomic"
operation.

The last time I peeked was in the hey days of Univac and CDC.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
One thing I love about having a website, is that when I complain about
something, I only have to do it once. It saves me endless hours of 
grumbling.

[toc] | [prev] | [next] | [standalone]

#22733

Am 05.03.2013 21:19, schrieb Roedy Green:
> On Tue, 5 Mar 2013 09:02:25 -0800 (PST), bob smith
> <bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
> who said :
> 
>> How do synchronized methods work "under the hood"?
>>
>> Is there some kind of byte associated with each object that acts as a semaphore?
> 
> At the hardware level these are usually handled by some sort of test
> and test instruction.  It tests if a byte is zero, and if it is, sets
> it to 1.  It locks out any other CPU or thread from interfering
> between the test and set.  If reports if the byte was zero to start
> (in other words we successfully locked.) Test and Set is an "atomic"
> operation.

Such test and set methods are implemented in Java's Atomic* classes
(e.g. AtomicInteger). However, you need more than that to implement a
proper mutex. What I would call a proper mutex puts a thread to sleep,
if it cannot lock the mutex. To do that, you need to tell the kernel
that the thread is suspended. As far as I know, Linux futexes do both:
they first check whether the mutex is locked by using some atomic
test+set, and if that fails they resort to syscalls:
http://en.wikipedia.org/wiki/Futex


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#22735

On Tue, 05 Mar 2013 23:44:34 +0100, Sven Köhler
<remove-sven.koehler@gmail.com> wrote, quoted or indirectly quoted
someone who said :

>Such test and set methods are implemented in Java's Atomic* classes
>(e.g. AtomicInteger). However, you need more than that to implement a
>proper mutex. What I would call a proper mutex puts a thread to sleep,
>if it cannot lock the mutex. To do that, you need to tell the kernel
>that the thread is suspended

I thought he was asking about what happens at the hardware level.
Thread context switching I think is still done with software.

Back in the 1990s I wrote a package in C to allow threads that ran on
a single CPU. Threads had to be well behaved and call "have a
conscience" periodically. It was remarkably simple, just save and
restore contexts.  It is quite bit more complicated when you can
interrupt threads in mid instruction or when you have multiple CPUs.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
One thing I love about having a website, is that when I complain about
something, I only have to do it once. It saves me endless hours of 
grumbling.

[toc] | [prev] | [next] | [standalone]

#22736

Roedy Green schrieb:
> On Tue, 05 Mar 2013 23:44:34 +0100, Sven Köhler
> <remove-sven.koehler@gmail.com> wrote, quoted or indirectly quoted
> someone who said :
>
>> Such test and set methods are implemented in Java's Atomic* classes
>> (e.g. AtomicInteger). However, you need more than that to implement a
>> proper mutex. What I would call a proper mutex puts a thread to sleep,
>> if it cannot lock the mutex. To do that, you need to tell the kernel
>> that the thread is suspended
>
> I thought he was asking about what happens at the hardware level.
> Thread context switching I think is still done with software.
>
> Back in the 1990s I wrote a package in C to allow threads that ran on
> a single CPU. Threads had to be well behaved and call "have a
> conscience" periodically. It was remarkably simple, just save and
> restore contexts.  It is quite bit more complicated when you can
> interrupt threads in mid instruction or when you have multiple CPUs.
>

You can google the OpenJDK source and
find jvm_raw_lock etc.. in mutex.cpp.

The Java locking uses a combination of
atomic instructions for a fast path
and subsequent parking of threads, which
is I guess a queueing thing.

Bottomline is that locking causes some
overhead, seen for example when someone
uses Vector instead of ArrayList. But the
fast path makes it also not that expensive,
so that a certain use of locking is
tollerable.

As an alternative one can sometimes use
algorithms that use ordinary destructive
instructions (i.e. object field write) in
such a way, that reentrant operations result.
Example from String:


     public int hashCode() {
         if (hash == 0)
            hash = .. compute hash ..
         return hash;
     }

In the above it could happen that more than
one thread computes the hash, if the check is
interleaved by a context switch. But it doesn't
do any harm, since String is immutable and always
the same hash is calculated.

Bye

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web