synchronization

[Thomas Jollans]

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

 

[Andrew Thompson]

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.

 

[Chris Uppal]

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 Smith]

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

 

[Tim Ward]

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.

 

[Michael Borgwardt]

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?

 

[Tim Ward]

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.

 

[Stephen Kellett]

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

 

[Adam Jenkins]

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.

 

[Stephen Kellett]

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

 

[Adam Jenkins]

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

 

[Stephen Kellett]

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

 

[Sudsy]

Stephen Kellett wrote:

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.

 

[Stephen Kellett]

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

 

[John C. Bollinger]

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
(e-mail address removed)