Question about synchronized

Discussion in 'Java' started by Matthias Kaeppler, Nov 12, 2005.

  1. Hi,

    say I have two different methods M1 and M2 which work on the same object
    O, whereas M1 is declared 'synchronized' while M2 is not.
    Now imagine I start two threads A and B, which keep calling M1 and M2
    respectively in an endless loop.

    As far as I can tell, if M1 is called by A, a lock is acquired on O and
    thus each call to M2 in B's context will result in the VM inserting B in
    the wait set until M1 has finished (this is only because M1 is
    synchronized).

    But what if M2 is called on O in B's context /first/ (remember it's not
    synchronized), and no lock is acquired on O, and while it's still
    computing, the VM decides to give A the CPU?
    Will M1 now be able to work on O, even though M2 hasn't finished yet?

    In other words, is in my case of two functions, two threads and one
    object the program only thread safe if /both/ methods M1 and M2 are
    declared synchronized? And what effects could arise from one being not
    not while the other is?

    Thanks,
    Matthias
     
    Matthias Kaeppler, Nov 12, 2005
    #1
    1. Advertisements

  2. Matthias Kaeppler

    VisionSet Guest

    No M1 is not sync'd and can be called at any time, by any thread.
    Yes, because no lock was ever obtained until M1 was called.
    As above!
     
    VisionSet, Nov 12, 2005
    #2
    1. Advertisements

  3. Matthias Kaeppler

    Roedy Green Guest

    Classes start with a upper case letter and methods with a lower case
    one.

    You have no idea how strange code that violates the Sun convention is
    to people who rigidly follow it.

    It is like saying a man named Barbi and a woman named Tex decided to
    get married. They hired a preacher named Bowser. Their pet dog was
    named Sheldon. The best Man's name was Cauliflower with cheese and
    the bridemaid was Duck a Limon.

    What colour tux should Sheldon wear?

    see http://mindprod.com/jgloss/codingconventions.html
     
    Roedy Green, Nov 12, 2005
    #3
  4. You obviously completely missed my point, did you even read my post
    beyond that line? ^^
    I was obviously referring to an artificial setup which ought to
    represent my problem. We call that abstraction.

    Regards,
    Matthias
     
    Matthias Kaeppler, Nov 12, 2005
    #4
  5. M1 /is/ synced, I suppose you mean M2?
    Okay, thanks.

    - Matthias
     
    Matthias Kaeppler, Nov 12, 2005
    #5
  6. Matthias Kaeppler

    VisionSet Guest

    To be fair, Roedy has a good point.
    When you stare at code all day, you just don't see entities starting with a
    capital as an Object.
    I only let it slip because you hadn't actually written any code, but I keep
    to the conventions in pros, because it means Java folk will get the meaning
    more quickly.
     
    VisionSet, Nov 12, 2005
    #6
  7. No, this is wrong. When B calls M2, it does not try to acquire
    the lock, and therefore does not discover that it is already
    locked by A. B (also C, D and E at the same time) is free to
    enter M2 regardless of whether anyone has the lock.
    Yes. Although no other threads will be able to enter M1 until A
    leaves it.
    That's right.

    Steve
     
    Steve Horsley, Nov 12, 2005
    #7
  8. Matthias Kaeppler

    VisionSet Guest

    err, yes
     
    VisionSet, Nov 12, 2005
    #8
  9. So thread A only calls M1, and thread B only calls M2? OK.
    No, that's not entirely correct. Thread A does lock O's monitor once at
    each entry to M1, and it unlocks the monitor once at each exit from M1,
    but that has no effect on any thread invoking /unsynchronized/ method M2.
    Yes. You should think of synchronization as protecting sections of code
    -- either blocks or methods -- not objects. It is in fact mostly a
    convenience that every object /has/ a monitor at all; the object whose
    monitor you use to synchronize a particular block of code does not have
    to have any particular relation to the class that owns the code.
    Synchronized methods automatically synchronize on the object they are
    invoked on, but with a synchronized block you specify which object's
    monitor is used. This is very important.
    If both M1 and M2 are synchronized then no more than one thread will
    ever execute in either one of them (collectively) at any particular
    time. This may be sufficient for thread safety, but it is not certain
    to be sufficient. The canonical example here is the Collections
    classes: suppose I have a Collection whose methods are all synchronized.
    Thread T1 gets the Collection's iterator and starts iterating through
    the elements. Meanwhile, thread T2 adds an element to the Collection in
    between T1's invocations of next(). The synchronization ensures that
    the Collection's internal state remains consistent and means that there
    is no data race in the sense that that term is used in the latest Java
    language spec. The synchronization of the individual methods does not
    prevent T1 from receiving a ConcurrentModificationException. The
    solution in this case is to put the whole iteration inside a block
    synchronized on the Collection.

    To get a grip on multithreaded programming in Java it is also important
    to understand the use and effects of Object.wait(), .notify(), and
    ..notifyAll(), and to appreciate the nondeterminism of the thread
    scheduler. Those are topics for another post, however.
     
    John C. Bollinger, Nov 12, 2005
    #9
  10. That's interesting. Doesn't that effectively render my synchronized
    function useless in terms of atomicity, when anyone can go ahead and
    call his/her unsynced methods on my object, even if I own that lock? ^^

    Regards,
    Matthias
     
    Matthias Kaeppler, Nov 12, 2005
    #10
  11. Heh, okay, I didn't expect anyone to be overstrained by referring to a
    method in uppercase... I'll keep it in mind :)
     
    Matthias Kaeppler, Nov 12, 2005
    #11
  12. I see.
    Yes, I was aware of the difference between synchronized being used as a
    statement as opposed to being used as a modifier for methods, but I
    wasn't sure about the mechanics between sychronized blocks of code (or
    methods) and such that aren't synchronized.
    That was quite insightful, thanks.

    Regards,
    Matthias
     
    Matthias Kaeppler, Nov 12, 2005
    #12
  13. Matthias Kaeppler

    Roedy Green Guest

    no, and I thought you should know why you are not getting as many
    responses as you expected.
     
    Roedy Green, Nov 12, 2005
    #13
  14. Matthias Kaeppler

    Roedy Green Guest

    People who persist in doing it are usually snotty brat know-it-alls
    who do it just to annoy the very people they are supposedly asking to
    help them. I doubt that was your intention.

    ..
     
    Roedy Green, Nov 12, 2005
    #14
  15. Are you trying to tell me that I received less responses than other
    people because I used uppercase notation for a method? I hope you know
    how ridiculous that sounds.
    But anyway, I already told you, next time I will remember that and use
    camel-case all the way to make you smile again! :D

    No seriously, I actually had no expectations at all about the quantity
    of responses since I rarely post here (I just don't use it as frequent
    as, say, C++), but I am happy with all responses so far (and already
    said so).

    Best regards,
    Matthias
     
    Matthias Kaeppler, Nov 12, 2005
    #15
  16. Matthias Kaeppler

    Roedy Green Guest

    YES!

    You piss people off when you do that.

    It is like top posting.
     
    Roedy Green, Nov 13, 2005
    #16
  17. Matthias Kaeppler

    Roedy Green Guest

    Obviously, you got at least one less than expected because I refused
    to answer your questions, and I usually answer posts..
     
    Roedy Green, Nov 13, 2005
    #17
  18. I hope you will grasp that no matter how ridiculous Roedy's assertion
    may sound to you, it is quite possibly true. Many newsgroup
    participants (in any group) are restrictive about which posts they read,
    and most are even more restrictive about which they respond to. Myself,
    I doubt whether I read 25% of the posts to this group. If a post is
    hard to read -- for whatever reason -- then it is likely that
    considerably fewer people will bother with it than otherwise would do.

    Also, taking the attitude that your post *deserves* attention, or any
    particular kind of response, does not resonate well on Usenet. If I had
    seen the exchange between you and Roedy before posting my response to
    your original message then I might not have bothered.
     
    John C. Bollinger, Nov 13, 2005
    #18
  19. Roedy Green coughed up:
    I'm not sure I see what he did as any different than saying

    If person X makes Y amount of money....

    He abstracted out the M1 not as the /identifier/ but the abstracted name for
    it. Meta meta meta meta meta....I just don't see an issue with it.
     
    Thomas G. Marshall, Nov 13, 2005
    #19
  20. Matthias Kaeppler coughed up:
    There is no lock honored unless all the participants that are intended to be
    locked out from each other are engaging in synchronization.

    If you have

    public class Hooey
    {
    public synchronized void m1() {...}
    public synchronized void m2() {...}
    public synchronized void m3() {...}
    public void m4() {....}
    }

    then m4() is free to be called and executed without regard to the mutex.
    That means it can do anything to the object. The full explanations of how
    this all works is beyond the scope of a usenet post.
     
    Thomas G. Marshall, Nov 13, 2005
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.