[jdom-interest] Thread safe question: OK for simultaneous read-only access?

[Joe Bowbeer]

Mark Bennett wrote:

> Sorry to be dense, but specifically, should simultaneous reading/traversal
> of a tree be OK?  As long as no modifications are made?

When multiple threads are involved, there should still be some kind of
synchronized hand-off between the producers and the readers.  Just because a
thread obtains a reference to a JDOM document doesn't mean that thread will
see the current state of the document's contents.  Because of potential
per-thread caching, the readers and writers should still synchronize on some
lock.

Brian Goetz's "Double-Checked Locking" articles in JavaWorld do a good job
of explaining the subtle details in the context of the broken Double-Checked
Lock idiom (DCL).

  http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html

JSR-133 is attempting to define the behavior of threads and locks in less
uncertain terms than they are defined in the current JLS.

  http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html


bob mcwhirter wrote:

> Since the underlying storage within the JDOM classes are from the
> Java Collections framework, you'll see 'fail-fast' behaviour should
> you commit a synchronization error.

Except that it's impossible for the Collections framework to reliably detect
synchronization errors without using some kind of synchronization itself --
and it doesn't.  The fail-fast mechanism in Collections can reliably guard
against someone iterating through a Collection and modifying the Collection
through a different method in the same thread.  It might by chance catch
concurrent modifications made in multiple threads, but is not guaranteed to.

> If you want to read and write across a shared document,
> then I suggest implementing a ReadWriteLock

Me, too.  By the way, there are some good implementations in Doug Lea's
util.concurrent package:

  http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/



--- original message ---

From: bob mcwhirter bob at werken.com
Date: Sun, 28 Oct 2001 01:49:46 -0500 (EST)

Reading and traversal are basically const operations (sorry for the
C++ throwback).  They have no side-effects, and thus, there is no
way for one thread to alter another's view of the underlying data.

As soon as you throw even 1 mutating event into the mix, though,
the results quickly become undefined.  Since the underlying storage
within the JDOM classes are from the Java Collections framework,
you'll see 'fail-fast' behaviour should you commit a synchronization
error.  This occurs only within the context of a node, and not
an entire Document.

If Thread-A is reading Element-1's list of attributes, and Thread-B
alters Element-1's list of attributes simultaneously, you'll witness
an exception thrown to Thread-A.  If Thread-B only modifies the
attributes of Element-5, then Thread-A will be unaware.  While this
won't throw an exception to Thread-A, it might radically change
the semantics of the document unbeknownest to Thread-A.

Thus:

If all threads *only* read, you're safe across the board.

If you want to read and write across a shared document, then I
suggest implementing a ReadWriteLock, associated with the Document
object, or similar, for maximum efficiency.

 -bob


On Sat, 27 Oct 2001, Mark Bennett wrote:

> Sorry to be dense, but specifically, should simultaneous reading/traversal
> of a tree be OK?  As long as no modifications are made?
>
> -----Original Message-----
> From: Jason Hunter [mailto:jhunter at acm.org]
> Sent: Saturday, October 27, 2001 10:18 AM
> To: mbennett at ideaeng.com
> Cc: jdom-interest at jdom.org
> Subject: Re: [jdom-interest] Thread safe question: OK for simultaneous
> read-only access?
>
> > JDOM is generally not thread safe, as I understand it.
>
> True.  We follow the same model as ArrayList, which is not by default
> thread safe.
>
> > It's suggested that
> > it not be used in such an environment.
>
> Not true.  It's simply suggested you manage your own thread safety.  See
> the FAQ for an explanation.
>
> -jh-
>