synchronization

Discussion in 'Java' started by Thomas Jollans, Dec 16, 2003.

  1. Considering:

    class X
    {
    synchronized void a()
    {
    this.b()
    }

    synchronized void b()
    {
    //acccess some variable in this class
    }
    }

    What happens if someone calls my_X_instance.a();? Will there be a deadlock?

    Thomas
    Thomas Jollans, Dec 16, 2003
    #1
    1. Advertising

  2. "Thomas Jollans" <> wrote in message
    news:brnibb$sj0$07$-online.com...
    > Considering:

    ....
    > What happens if someone calls my_X_instance.a();? Will there be a

    deadlock?

    Why? What happens when _you_ call it?

    Learning is vastly assisted by experimentation.

    --
    Andrew Thompson
    * http://www.PhySci.org/ PhySci software suite
    * http://www.1point1C.org/ 1.1C - Superluminal!
    * http://www.AThompson.info/andrew/ personal site
    Andrew Thompson, Dec 16, 2003
    #2
    1. Advertising

  3. Thomas Jollans

    Chris Uppal Guest

    Thomas Jollans wrote:

    > What happens if someone calls my_X_instance.a();? Will there be a
    > deadlock?


    No.

    Once a thread owns the lock on a specific object(s) it can enter any further
    blocks/methods that are synchronized on the exact same object(s).

    -- chris
    Chris Uppal, Dec 16, 2003
    #3
  4. Thomas Jollans

    Chris Smith Guest

    Thomas Jollans wrote:
    > Considering:
    >
    > class X
    > {
    > synchronized void a()
    > {
    > this.b()
    > }
    >
    > synchronized void b()
    > {
    > //acccess some variable in this class
    > }
    > }
    >
    > What happens if someone calls my_X_instance.a();? Will there be a deadlock?


    No, it will work fine. Monitor locks are recursive, to b simply aquires
    a recursive second lock on the monitor for the X instance.

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Dec 16, 2003
    #4
  5. Thomas Jollans

    Tim Ward Guest

    "Andrew Thompson" <> wrote in message
    news:%7IDb.55201$...
    >
    > Learning is vastly assisted by experimentation.


    Except for learning programming languages etc, where experimentation is the
    last resort in the face of inadequate documentation.

    Experimentation might tell you what one particular compiler does in one
    particular environment with one particular set of data on one particular
    Tuesday afternoon, but you cannot deduce from that that your code will work
    the same way in any other circumstances unless the language spec says so.

    --
    Tim Ward
    Brett Ward Limited - www.brettward.co.uk
    Tim Ward, Dec 17, 2003
    #5
  6. Tim Ward wrote:
    >>Learning is vastly assisted by experimentation.

    >
    >
    > Except for learning programming languages etc, where experimentation is the
    > last resort in the face of inadequate documentation.
    >
    > Experimentation might tell you what one particular compiler does in one
    > particular environment with one particular set of data on one particular
    > Tuesday afternoon, but you cannot deduce from that that your code will work
    > the same way in any other circumstances unless the language spec says so.


    Theoretically yes, but in real life, many questions *are* answered accurately
    (and, most importantly, quickly) by simply trying it out. Especially questions
    like "If I do X, does Y happen?".

    This is, in fact, the case so often that I'd say it's only worth the bother to
    consult the language spec if experimentation is inconclusive or you have an
    actual reason to believe that the result may not always be the same.

    After all, *theoretically* your particular compiler may implement the spec
    incorrectly. Would you therefore suggest that one should always primarily
    consult the compiler source code?
    Michael Borgwardt, Dec 17, 2003
    #6
  7. Thomas Jollans

    Tim Ward Guest

    "Michael Borgwardt" <> wrote in message
    news:brpavd$5v15h$-berlin.de...
    >
    > After all, *theoretically* your particular compiler may implement the spec
    > incorrectly. Would you therefore suggest that one should always primarily
    > consult the compiler source code?


    Absolutely not. If the compiler doesn't follow the spec it's broken: get it
    fixed, in the meantime code a workaround that will give the right answers
    *both* with your currently broken compiler *and* with any properly working
    compiler you might come across.

    This is a trap some open source weenies fall into because they've never
    learnt how to, or can't be bothered to, do documentation. They say: "It's
    open source, fix your attitude, stop whining about the lack of
    documentation, read the source code".

    Yeah, right. The source code tells you what *this* implementation does
    *today*, it doesn't tell you what the *contract* is for the API, so you
    haven't a clue whether you're doing something that's going to break when
    someone changes the library tomorrow; plus, of course, the person changing
    the library tomorrow doesn't know the contract either, because it's not
    documented and folklore wears out, so doesn't know whether they're breaking
    it or not, so they will.

    --
    Tim Ward
    Brett Ward Limited - www.brettward.co.uk
    Tim Ward, Dec 17, 2003
    #7
  8. In message <brpdhq$63rq8$-berlin.de>, Tim Ward
    <> writes
    >This is a trap some open source weenies fall into because they've never
    >learnt how to, or can't be bothered to, do documentation. They say: "It's
    >open source, fix your attitude, stop whining about the lack of
    >documentation, read the source code".


    Also a good reason why Java and C# fail compared to C++ and Modula-2 and
    its descendants. Java and C# have the API as part of the class
    implementation (thus you can't help but decide to read the source whilst
    examining the API), C++ and Modula-2 have the API defined separately (in
    header files and definition files). If you need to look at the source
    code to use an API either:

    1) The documentation is not good enough (often the case)
    2) The API is poorly thought out (I can think of some Java and Microsoft
    APIs that fit this bill.)
    3) You don't understand what you are doing (this is not intended as an
    insult).
    4) The source code is broken

    >Yeah, right. The source code tells you what *this* implementation does
    >*today*, it doesn't tell you what the *contract* is for the API, so you
    >haven't a clue whether you're doing something that's going to break when
    >someone changes the library tomorrow; plus, of course, the person changing
    >the library tomorrow doesn't know the contract either, because it's not
    >documented and folklore wears out, so doesn't know whether they're breaking
    >it or not, so they will.


    Completely agree. I know people that write great code and don't write
    comments, arguing "read the code". They completely miss the point. The
    code tells you what the code is doing. The comments tell you what the
    author of the code intended the code "should" do. In an ideal world the
    two views coincide. In the real world, the author of the code made a
    mistake and the comments allow you to identify that.

    Sadly, in one case, the individual I am thinking of still doesn't
    understand this subtle difference and is now a manager...

    Stephen
    --
    Stephen Kellett
    Object Media Limited http://www.objmedia.demon.co.uk
    RSI Information: http://www.objmedia.demon.co.uk/rsi.html
    Stephen Kellett, Dec 17, 2003
    #8
  9. Thomas Jollans

    Adam Jenkins Guest

    Stephen Kellett wrote:
    > In message <brpdhq$63rq8$-berlin.de>, Tim Ward
    > <> writes
    >> This is a trap some open source weenies fall into because they've never
    >> learnt how to, or can't be bothered to, do documentation. They say: "It's
    >> open source, fix your attitude, stop whining about the lack of
    >> documentation, read the source code".

    >
    >
    > Also a good reason why Java and C# fail compared to C++ and Modula-2 and
    > its descendants. Java and C# have the API as part of the class
    > implementation (thus you can't help but decide to read the source whilst
    > examining the API), C++ and Modula-2 have the API defined separately (in
    > header files and definition files).


    Where did you get this idea? I have *never* had to look at the source
    code for the any of the standard Java APIs (I have looked out of
    curiosity.) That's what Javadoc is for. C++ header files are as much a
    disadvantage as an advantage IMO, and I don't think looking in a C++
    header file is any more of a substitute for documentation than looking
    at the output of javap for a Java class. If noone has written
    documentation for an API, you're going to have to read the source code
    to see what everything does anyway, even if the method and parameter
    names are intuitive.
    Adam Jenkins, Dec 18, 2003
    #9
  10. In message <>, Adam Jenkins
    <> writes
    >Stephen Kellett wrote:
    >> Also a good reason why Java and C# fail compared to C++ and
    >>Modula-2 and its descendants. Java and C# have the API as part of the
    >>class implementation (thus you can't help but decide to read the
    >>source whilst examining the API), C++ and Modula-2 have the API
    >>defined separately (in header files and definition files).

    >
    >Where did you get this idea?


    From Java programmers I was talking to. Its not something I do myself,
    but some Java programmers do, indeed one, to my amazement cited it as a
    principle *advantage* of Java over other languages. Given that this
    particular individual is a bright, thoughtful guy and definitely above
    average when it comes to software engineers, some other Java programmers
    most likely will have come to the same, but incorrect, conclusion.

    >I have *never* had to look at the source code for the any of the
    >standard Java APIs (I have looked out of curiosity.)


    I never said you did.

    >That's what Javadoc is for.


    Couldn't agree more, don't particularly like the output, but it does the
    job.

    >C++ header files are as much a disadvantage as an advantage IMO,
    >and I don't think looking in a C++ header file is any more of a
    >substitute for documentation than looking at the output of javap for a
    >Java class.


    Depends on how well the class is designed and how well the API
    parameters are named. When writing software I spend much more time
    looking at header files than at the documentation, except where the
    header files are for a standard library, then I look at the
    documentation (as the header files are not likely to change/be out of
    step with the documentation).

    >If noone has written documentation for an API, you're going to have to
    >read the source code to see what everything does anyway, even if the
    >method and parameter names are intuitive.


    I disagree, if the methods and parameters are named well and the class
    name is sensible, it is often possible to use the API with no other
    documentation. I am assuming the header file/whatever does have comments
    in it describing the function. Most well-written container classes
    (regardless of language) fit this definition nicely.

    That is no excuse for not having the documentation though, or putting
    comments in the header file (where header files or equivalents exist).

    Seriously off-topic now...

    Stephen
    --
    Stephen Kellett
    Object Media Limited http://www.objmedia.demon.co.uk
    RSI Information: http://www.objmedia.demon.co.uk/rsi.html
    Stephen Kellett, Dec 18, 2003
    #10
  11. Thomas Jollans

    Adam Jenkins Guest

    Stephen Kellett wrote:
    > In message <>, Adam Jenkins
    > <> writes
    >> If noone has written documentation for an API, you're going to have to
    >> read the source code to see what everything does anyway, even if the
    >> method and parameter names are intuitive.

    >
    > I disagree, if the methods and parameters are named well and the class
    > name is sensible, it is often possible to use the API with no other
    > documentation. I am assuming the header file/whatever does have comments
    > in it describing the function. Most well-written container classes
    > (regardless of language) fit this definition nicely.


    I'm all in favor of using good identifier names, and sure, you can get
    an idea of what a function or parameter is for by the name. But you
    can't tell, for instance, that String.indexOf(char) will return -1 if
    the character isn't found, or that the correct argument to get the first
    column value from java.sql.ResultSet.getString(int) is 1, or that
    calling java.sql.Connection.close() on an already closed connection is a
    no-op, etc. Basically, for any non-trivial API, if it's not documented
    you're going to have to look at the source code to know if you're using
    it correctly. My point is that I don't see the fact that C++ has
    separate header files as being any advantage over Java, since unless the
    header file is documented it's not going to be a substitute for looking
    at the source anyway. And if it is documented, then Javadoc does just
    as well or better in my opinion.

    Adam
    Adam Jenkins, Dec 18, 2003
    #11
  12. In message <>, Adam Jenkins
    <> writes
    >to have to look at the source code to know if you're using it
    >correctly. My point is that I don't see the fact that C++ has separate
    >header files as being any advantage over Java, since unless the header
    >file is documented it's not going to be a substitute for looking at the
    >source anyway. And if it is documented, then Javadoc does just as well
    >or better in my opinion.


    As I've already stated in my reply to what you are replying, I am
    assuming the author has put comments in the header file (as they would
    above the function definition in both C++ and Java, the latter of which
    could be put through javadoc or an equivalent tool for C++).

    Not everything gets put through javadoc or the C++ equivalent. Thats a
    fact. Not all environments are like that. Some places don't even comment
    the code (don't get me started on how stupid that is). I was commenting
    on the fact that because the definition of the API is separate from the
    implementation it discourages, and sometimes prevents people from
    peeping under the hood. Thats a good thing.

    The point is, in the absence of the autogenerated documentation, for C++
    all you need is the header file (you can't peek at the source), for Java
    and C#, that is not possible (although you have alluded to a javap tool,
    that I assume generates a header file equivalent).

    You are correct that complex APIs can usually only be used with proper
    documentation, I wasn't claiming anything else. You claimed that (all by
    implicitness) APIs can't be used without documentation. I stated and
    demonstrated otherwise. Many commonly used APIs are container APIs. I
    can't remember all the STL variants. As for using a database, I'd be
    sure to lookup the documentation - how often do you write DB queries?
    Not often, once they are done, thats it. Often unchanged for years. Why
    would you bother remember the details of an API you don't use that
    often.

    In case you have mistaken this for a language war, it isn't. I use
    assembler, C++ and Java regularly. I have used Modula-2 in the past, and
    I write software tools supporting C++, Java and Python. One project I'm
    involved with, we chose Java for platform independence, only to be
    bogged down with native method calls to interact with hardware and
    speech synthesis (we started that project in 1997). I am not a language
    bigot.

    I do happen to believe that C++ is superior to Java and C# by quite some
    margin, but thats more to do with what you can't do with Java and C#
    that you can do with C/C++ (low level stuff), and because of the way
    Java has to be written you end up in certain stylistic straight-jackets
    I don't like (in C++ you have the choice - of course thats the point of
    Java and C# - to remove the choice (in the name of making programming
    "easier")).

    I also think both Java and C# (and any .net language) have serious
    problems with synchronization that are brought about by the notion of
    every object having its own monitor.

    So far I have only seen one article in print (in MSDN of all places)
    which describes these short-comings. I'm not going to get drawn into a
    discussion on that - if you want to read the article search recent
    issues of MSDN on Microsoft's website discussing monitors. The comments
    in the article apply equally to Java.

    Stephen
    --
    Stephen Kellett
    Object Media Limited http://www.objmedia.demon.co.uk
    RSI Information: http://www.objmedia.demon.co.uk/rsi.html
    Stephen Kellett, Dec 18, 2003
    #12
  13. Thomas Jollans

    Sudsy Guest

    Re: synchronization & C++ vs Java documentation

    Stephen Kellett wrote:
    <snip>
    > The point is, in the absence of the autogenerated documentation, for C++
    > all you need is the header file (you can't peek at the source), for Java
    > and C#, that is not possible (although you have alluded to a javap tool,
    > that I assume generates a header file equivalent).

    <snip>

    But C++ doesn't require that you even create a header file! You could
    define everything in a single place. Only "usual practice" might
    dictate creation of the header file. It's the same with javadoc
    comments in Java code: not mandatory but generally a good idea.
    Sudsy, Dec 19, 2003
    #13
  14. Re: synchronization & C++ vs Java documentation

    In message <>, Sudsy
    <> writes
    >But C++ doesn't require that you even create a header file!


    Quite true, but then to use that class in a separate file what do you
    do? Include the source file and get multiple implementations of the
    class in your exe? The only good reason for not creating a header file
    is for creating a local class. You don't see that done very often.

    Stephen
    --
    Stephen Kellett
    Object Media Limited http://www.objmedia.demon.co.uk
    RSI Information: http://www.objmedia.demon.co.uk/rsi.html
    Stephen Kellett, Dec 19, 2003
    #14
  15. Re: synchronization & C++ vs Java documentation

    Stephen Kellett wrote:

    > In message <>, Sudsy
    > <> writes
    >
    >> But C++ doesn't require that you even create a header file!

    >
    >
    > Quite true, but then to use that class in a separate file what do you
    > do? Include the source file and get multiple implementations of the
    > class in your exe? The only good reason for not creating a header file
    > is for creating a local class. You don't see that done very often.


    With a Java class, on the other hand, you just use it. The equivalent
    to the interface definitions found in a C / C++ header file are part of
    a Java class file. That completely prevents problems related to version
    skew between headers and compiled classes (although it doesn't
    altogether avoid version-related class incompatibilities), and even
    makes it possible (and not too difficult) for a tool to extract the API
    description from a compiled class. This is something that can be done
    in Java, but not easily in C / C++.

    That is not meant to contest the fact that there are tasks for which a C
    / C++ solution is required, however, or the fact that Java places
    restrictions on class usage that in C++ are considered matters of style.


    John Bollinger
    John C. Bollinger, Dec 22, 2003
    #15
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. arcvonz

    System Time synchronization

    arcvonz, Aug 23, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    475
    Sam Santiago
    Aug 23, 2004
  2. John

    Flip Flop Synchronization

    John, Jan 3, 2004, in forum: VHDL
    Replies:
    3
    Views:
    9,656
    valentin tihomirov
    Jan 5, 2004
  3. Simon
    Replies:
    1
    Views:
    610
    tbx135
    Jan 9, 2004
  4. prav

    regarding synchronization

    prav, Feb 18, 2004, in forum: VHDL
    Replies:
    5
    Views:
    1,286
    Jos De Laender
    Feb 21, 2004
  5. deep
    Replies:
    0
    Views:
    461
Loading...

Share This Page