David Holmes wrote,
> Miles Sabin wrote:
> > I don't think you can have it both ways. Either dummy reads/writes
> > are a viable and comprehensible technique, in which case
> > {read,write}Barrier() would be even more so; or
> > {read,write}Barrier() is not a viable and comprehensible
> > technique, in which case dummy reads/writes aren't either (and
> > maybe volatile accesses should be full two way barriers).
>
> I totally agree - so please don't change your mind Miles :)
Too late ... I already have ;-)
> If "tricky" situations will require dummay accesses then lets not
> have everyone reinvent the wrong trick for fixing things. Having
> some codified helper classes/methods has got to be better than ad-
> hoc solutions being rewritten over and over.
This sounds like a good idea, but I don't think it works out in any
particularly useful way.
Here's what such a class might look like,
public final class NotAMonitor
{
private volatile boolean force;
public void enter() // reads are equivalent to monitor enters
{
boolean temp = force;
}
public void exit() // writes are equivalent to monitor exits
{
force = true;
}
}
Now here's how it would fit in to Bills reworking of the optimistic
readers example,
volatile int vno = 0;
NotAMonitor notAMonitor = new NotAMonitor();
int a,b;
synchronized void inc(int x)
{
int oldVersion = vno;
vno = oldVersion+1;
notAMonitor.enter(); /* Don't allow accesses to be hoisted */
a += x;
b += x;
vno = oldVersion+2;
}
/* unsynchronized */
int prod()
{
int v1 = vno; /* pre-inspect */
int t1 = a;
int t2 = b;
notAMonitor.exit(); /* force all accesses to be committed */
int v2 = vno; /* post-inspect */
if (v1 == v2 && v1%2 == 0)
return t1*t2; /* commit */
else ... /* abort */
}
Does this really help? I think only to a _very_ small extent, and at
the cost of an object allocation and the loss of the possiblity of
doing anything more useful with the encapsulated volatile.
Cheers,
Miles
-- Miles Sabin InterX Internet Systems Architect 27 Great West Road +44 (0)20 8817 4030 Middx, TW8 9AS, UK msabin@interx.com http://www.interx.com/------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:33 EDT