How do you handle clones?

[Alix]

Hi. This is my second question. Here goes the intro of the message
again:

[intro]
I'm currently translating an STM from Java to C# and I'd appreciate
some insight. I'm having trouble translating it because it relies
heavily on deuce for the low-level stuff, but I don't have anything
like deuce in C# so I have to take care of all that myself :$.

I've been browsing through your code and it's way more complex than
what I have time for, but there a couple of points that interest me in
particular.
[/intro]

And here goes the second question: How do you handle clones? I'll
elaborate: a write access to a field of an atomic object triggers a
call to:

public void onWriteAccess(Object obj, Object value, long field)

or one of the other onWriteAccess methods. I'm particularly interested
in this one because the value is an object reference. I imagine that
'value' is (a reference to) a clone of the field at the time of the
access? Or is it a reference to the actual field?

In case it's a clone, how do you handle the following scenario? Say
you have this class:

@Atomic
public class MyAtomicObject {
private SomeClass someField;
}

and you have a MyAtomicObject myAtomicObject, on which you do this:

SomeClass referenceToSomeField = myAtomicObject.someField;

myAtomicObject.someField is detected as a read access and results in
an invocation of:

public Object onReadAccess(Object obj, Object value, long field)

(of the class Context), in which 'value' isn't a reference to the
actual field, but a clone of the field at the time of the access. So
referenceToSomeField is actually a reference to the clone.

Then the transaction does a series of things, including (in our
example) putting a reference to this clone in a structure (e.g. a
list) that will become visible to other transactions when it commits.
Then it commits, and the global copy of the object is updated with the
contents of the clone.

However, the structure (the list) still contains a reference to the
clone, which doesn't make sense at all: there are references to the
(updated) global copy and references to the clone, when in fact there
should be just one object now that the transaction has committed, and
all references should point to it.

How do you handle this?

Or, in case 'value' isn't a clone:
a) How is that safe? Someone could update the global copy while we
read 'value' and we may read inconsistent data.
b) Do you use clones in some other place, with similar problems?
(references to different objects). And if so, how do you handle that?

Again, I realise this may require a pretty long explanation -- which
I'd love, but if you don't have the time I'd appreciate any pointers
you can give me. For example if you could refer me to where you handle
this in your code it would be great.

Thanks so much.

[Guy Korland]

As I wrote in my previous answer Deuce is Method based and not Objects based.
Also Deuce doesn't clone any object this is up to the underline STM algorithm implementation.
Currently, both implementations (LSA & TL2), doesn't clone the changed fields, but keep a writeset that change the original object on commit.

Guy

--
You received this message because you are subscribed to the Google Groups "Deuce-STM" group.
To post to this group, send email to deuc...@googlegroups.com.
To unsubscribe from this group, send email to deuce-stm+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/deuce-stm?hl=en.

[Alix]

> Deuce doesn't clone any object this is up to the underline STM
> algorithm implementation.
> Currently, both implementations (LSA & TL2), doesn't clone the changed
> fields, but keep a writeset that change the original object on commit.

Yes, this is what I do as well. However I understood that the "field"
you pass to the context is necessarily a field of an atomic object
(which as you say is a concept that doesn't exist in deuce), which
implied the need to clone the object, since you don't go any deeper
into its own fields. It's a bit long to explain and I don't want to
bore you :)
Anyway, with your approach of detecting *every* access (not only to
particular fields) it's true that there is no need of cloning. I like
it way better that way. Hopefully I'll find a way to detect accesses
in C#.

Again, thanks for your answer. :)