[
https://issues.apache.org/jira/browse/CAMEL-5835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506883#comment-13506883
]
Peter Sramka edited comment on CAMEL-5835 at 11/29/12 10:22 PM:
----------------------------------------------------------------
h4.Background
Java concurrency is a deep and subtle topic. I have found that knowledge of
this topic is often lacking, even with very intelligent and experienced Java
programmers. Consequently, there is much Java code in existence with
concurrency bugs.
Concurrency in Java is intimately inter-twined with the Java Memory Model. The
Java Memory Model was updated via _JSR 133: Java Memory Model and Thread
Specification Revision_. Starting with Java 2 SE 5.0, all Java Virtual Machines
are required to use this updated Java Memory Model. The results of _JSR 133_
are included in the Java Platform Standard Edition Documentation. This _JSR 133
(Java Memory Model) FAQ_ is a brief, but very well-written, synopsis of _JSR
133_: http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
A basic discussion of Java concurrency is contained in the _Essential Classes
Trail_ within the _Trails Covering the Basics_ of _The Java Tutorials_:
http://docs.oracle.com/javase/tutorial/essential/concurrency/index.html
This page from the _Essential Classes Trail_ briefly describes _Memory
Consistency Errors_:
http://docs.oracle.com/javase/tutorial/essential/concurrency/memconsist.html
For a more detailed discussion of Java concurrency, I highly recommend the book
_Java Concurrency in Practice_, which was written by the primary members of the
_JSR 166_ Expert Group (_Concurrency Utilities_): http://jcip.net/
Please be advised that there are many sources of so-called "expert" information
about Java concurrency, including published books and lectures of prestigious
university professors, that are filled with fundamental technical errors.
Consequently, there are many smart Java programmers who believe certain things
about Java concurrency that are just plain wrong. As an example, _The
"Double-Checked Locking is Broken" Declaration_ exposes one widely-used, but
flawed, technique:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
----
h4.Thread-Safe Classes
There are many techniques for writing thread-safe code, but one of the simplest
and most effective is to write thread-safe classes. Here are a couple of
excellent quotes from page 18 of _Java Concurrency in Practice_
(http://jcip.net/):
"A class is _thread-safe_ if it behaves correctly when accessed from multiple
threads, regardless of the scheduling or interleaving of the execution of those
threads by the runtime environment, and with no additional synchronization or
other coordination on the part of the calling code."
"Thread-safe classes encapsulate any needed synchronization so that clients
need not provide their own."
A class is "accessed from multiple threads" when:
* Any instance of that class is "accessed from multiple threads"
or
* The class object itself -- the collection of all static fields and methods of
the class -- is "accessed from multiple threads".
Note that the statements above do not include the phrase "accessed from
multiple threads _simultaneously_". It is a widely-held, but incorrect belief,
that if a class is never accessed by more than one thread at a time, then all
thread-safety considerations may be safely ignored for that class. If a class
is accessed from multiple threads, but not simultaneously, mutual exclusion is
not a concern, but memory visibility is. For more information about memory
visibility and the related topic of memory consistency errors, please refer to
the previous section.
To determine if a particular class is thread-safe, all of the following must be
analyzed:
* The source code of the class in question
* The source code of all classes that the class in question extends either
directly or indirectly
* The source code of all interfaces that the class in question implements
either directly or indirectly
was (Author: petesramka):
h4.Background
Java concurrency is a deep and subtle topic. I have found that knowledge of
this topic is often lacking, even with very intelligent and experienced Java
programmers. Consequently, there is much Java code in existence with
concurrency bugs.
Concurrency in Java is intimately inter-twined with the Java Memory Model. The
Java Memory Model was updated via _JSR 133: Java Memory Model and Thread
Specification Revision_. Starting with Java 2 SE 5.0, all Java Virtual Machines
are required to use this updated Java Memory Model. The results of _JSR 133_
are included in the Java Platform Standard Edition Documentation. This _JSR 133
(Java Memory Model) FAQ_ is a brief, but very well-written, synopsis of _JSR
133_: http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
A basic discussion of Java concurrency is contained in the _Essential Classes
Trail_ within the _Trails Covering the Basics_ of _The Java Tutorials_:
http://docs.oracle.com/javase/tutorial/essential/concurrency/index.html
This page from the _Essential Classes Trail_ briefly describes _Memory
Consistency Errors_:
http://docs.oracle.com/javase/tutorial/essential/concurrency/memconsist.html
For a more detailed discussion of Java concurrency, I highly recommend the book
_Java Concurrency in Practice_, which was written by the primary members of the
_JSR 166_ Expert Group (_Concurrency Utilities_): http://jcip.net/
Please be advised that there are many sources of so-called "expert" information
about Java concurrency, including published books and lectures of prestigious
university professors, that are filled with fundamental technical errors.
Consequently, there are many smart Java programmers who believe certain things
about Java concurrency that are just plain wrong. As an example, _The
"Double-Checked Locking is Broken" Declaration_ exposes one widely-used, but
flawed, technique:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
h4.Thread-Safe Classes
There are many techniques for writing thread-safe code, but one of the simplest
and most effective is to write thread-safe classes. Here are a couple of
excellent quotes from page 18 of _Java Concurrency in Practice_
(http://jcip.net/):
"A class is _thread-safe_ if it behaves correctly when accessed from multiple
threads, regardless of the scheduling or interleaving of the execution of those
threads by the runtime environment, and with no additional synchronization or
other coordination on the part of the calling code."
"Thread-safe classes encapsulate any needed synchronization so that clients
need not provide their own."
A class is "accessed from multiple threads" when:
* Any instance of that class is "accessed from multiple threads"
or
* The class object itself -- the collection of all static fields and methods of
the class -- is "accessed from multiple threads".
Note that the statements above do not include the phrase "accessed from
multiple threads _simultaneously_". It is a widely-held, but incorrect belief,
that if a class is never accessed by more than one thread at a time, then all
thread-safety considerations may be safely ignored for that class. If a class
is accessed from multiple threads, but not simultaneously, mutual exclusion is
not a concern, but memory visibility is. For more information about memory
visibility and the related topic of memory consistency errors, please refer to
the previous section.
To determine if a particular class is thread-safe, all of the following must be
analyzed:
* The source code of the class in question
* The source code of all classes that the class in question extends either
directly or indirectly
* The source code of all interfaces that the class in question implements
either directly or indirectly
> XPathBuilder is documented as being thread-safe, but it has thread-safety
> bugs.
> -------------------------------------------------------------------------------
>
> Key: CAMEL-5835
> URL: https://issues.apache.org/jira/browse/CAMEL-5835
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Environment: This bug is not environment specific.
> Reporter: Peter Sramka
> Labels: thread-safety
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> The javadoc for org.apache.camel.builder.xml.XPathBuilder states that it is
> thread-safe, but an inspection of the source code in the trunk reveals that
> there are thread-safety bugs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
