[concurrency-interest] Transactional memory on GCC 4.7.0, what about Java?
gregg at cytetech.com
Tue Nov 22 09:04:11 EST 2011
A few years back, I built a multi-machine system which required that all
machines have a mirrored copy of the systems database, and that the change of
database content be synchronized with the operational data used by the software
on each machine, and on any connected client computer system.
I built the transactional operations around the use of the Jini transactional
services. I create the synchronization around a mesh network, that was
structured around an InvocationHandler which received inbound calls and
guaranteed they only passed into the JVM once (within a small time interval),
but also had references to all connected clients. The transaction join happened
on the inbound call. Each method of the service API included a "CallContext"
argument which held the transaction ID and other information.
I used an interface with "onCommit", "onPrepare" and "onAbort" methods in the
service API methods. The object took the call context, joined the transaction
specified, placed itself into a static container (to maintain the reference
chain), and then waited for the transaction owner to act.
This is pretty much the best model that I could imagine which would allow the
transactional model to work across all the machine with a lose coupling (the
mesh network makes it unnecessary to worry about who is a client).
Clients would connect to a server and register themselves as a listener. They
were called out to, on commit, and had no ability to lodge a rejection on
prepare or commit. They just took the call passed to them, and acted on it.
This keeps clients from interfering with the forward progress of the system, and
they can get a repaired view, by restarting. In a sense, their view of the
system was read only (they couldn't argue about the ability to commit), but they
could modify the system transactionally.
I was not aware of the work at MS labs regarding their use of the model, but was
driven by the mechanisms available with Jini's transactional services and the
Yes, there is quite a bit of "code" involved to make this happen, but once you
have the system wired this way, extension of the API and actions of the clients
are pretty much as they would be for any simple client-server or "external I/O
Hiding the complexity of "I/O" or "remote calls" will never be viable without an
mechanism for the application to deal with "partial failure." The RMI and later
Jini (now housed in the Apache River project) work around remoting really
demonstrates how to do transactional computing with arbitrary participants.
On 11/21/2011 5:26 PM, Guy Korland wrote:
> First, I think this is a discussion that should be done as part of a JSR.
> Meaning, I think the wheels should start moving and then we'll carve out the
> best solution.
> As for your questions:
> 1. There're two realistic options to handle I/O and one naiive.
> In other words (a) you can ignore I/O or Native code call as you do with
> I/O or Native call when called under a lock context (You don't enforce any
> memory semantic). (b) you can abort any transaction trying to get outside the
> scope of the JVM. (c) you can hope for transactional I/O but it won't help for
> Native method call.
> I think a realistic solution should go with (b).
> 2. The semantic we choose in DeuceSTM was to commit a transaction that throws an
> application Exception, and that since (sadly) throwing an Exception is a valid
> way to return from method in java and pretty common. Also again when running
> under a context of coarse grained lock Exception is a valid way to get out of it.
> Date: Mon, 21 Nov 2011 23:03:31 +0100
> From: R?mi Forax <forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>>
> To: concurrency-interest at cs.oswego.edu
> <mailto:concurrency-interest at cs.oswego.edu>
> Subject: Re: [concurrency-interest] Transactional memory on GCC 4.7.0,
> what about Java?
> Message-ID: <4ECACAB3.3000001 at univ-mlv.fr <mailto:4ECACAB3.3000001 at univ-mlv.fr>>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> On 11/21/2011 08:04 PM, Guy Korland wrote:
> > Not all the issues are solved, but it seems like most of the issues
> > have good answers.
> > Also, notice that in .NET they have issues which Java doesn't have
> > like Native code and pointers in C++.
> > Guy
> And how do you solve the IO problems (when you retry) ?
> Also the semantics chosen by Microsoft when an exception is thrown
> and the one chosen by GCC is not the same.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest