support for "read through" and "write behind" gettr/settrs (in addition to JBI) about hugecollections-old HOT 25 CLOSED

Musing Openly: could there be any value to OpenHFT generating "read through" and "write behing" impl capabilty (from the standard JBI user provided interface)? In may be useful as it could deliver to the user an easier API for crossing read/write barrier(s) across PIDs?

e.g. where before my use of a spin-busy wait loop coded as

//Left PingPong Player
double _coupon = 4.0;
bondOffHeap.setCoupon(_coupon);  // won't cross write barrier to /dev/shm
while (_coupon == 4.0) {
       _coupon = bondOffHeap.getCoupon();  // won't cross read barrier to /dev/shm
}

left me without the effect I was seeking (I needed to do CASCoupon()), If OpenHFT could have taken my JBI (now with addl signatures for ' read through ' and 'write behind
) -- and generated an appropriate impl via the Runtime-Compiler, maybe my ambition to code a new spin-busy wait loop as follows could be OpenHFT supported:

//Left PingPong Player
double _coupon = 4.0;
bondOffHeap.setWriteBehindCoupon(_coupon);  // will cross write barrier to /dev/shm
while (_coupon == 4.0) {
       _coupon = bondOffHeap.getReadThroughCoupon();  // will cross read barrier to /dev/shm
}

Again, just musing openly. Using CAS works perfectly ... I'm just thinking of something that may be super simple to code from a user API view.

from hugecollections-old.

@Cotton-Ben sorry about that. My cut-n-paste reply to this issue failed. I meant to say "+1"

from hugecollections-old.

We could support volatile read and write, (the underlying library does)
however I think using a lock or CAS is safer.

If there is a really good use case for this, we could add it.

On 4 June 2014 16:43, Frank-Bradley [email protected] wrote:

Musing Openly: could there be any value to OpenHFT generating "read
through" and "write behing" impl capabilty (from the standard JBI user
provided interface)? In may be useful as it could deliver to the user an
easier API for crossing read/write barrier(s) across PIDs?

e.g. where before my use of a spin-busy wait loop coded as

//Left PingPong Player
double _coupon = 4.0;
bondOffHeap.setCoupon(_coupon); // won't cross write barrier to /dev/shm
while (_coupon == 4.0) {
_coupon == bondOffHeap.getCoupon(); // won't cross read barrier to /dev/shm
}

left me without the effect I was seeking (I needed to do CASCoupon()), If
OpenHFT could have taken my JBI (now with addl signatures for ' read
through ' and 'write behind
) -- and generated an appropriate impl via the Runtime-Compiler, maybe my
ambition to code a new spin-busy wait loop as follows could be OpenHFT
supported:

//Left PingPong Player
double _coupon = 4.0;
bondOffHeap.setWriteBehindCoupon(_coupon); // will cross write barrier to /dev/shm
while (_coupon == 4.0) {
_coupon == bondOffHeap.getReadThroughCoupon(); // will cross read barrier to /dev/shm
}

Again, just musing openly. Using CAS works perfectly ... I'm just thinking
of something that may be super simple to code from a user API view.

—
Reply to this email directly or view it on GitHub
#29.

from hugecollections-old.

@peter-lawrey : That would be awesome from the vantage point of delivering a super simple user API view. IMHO the use of CAS-like capability and API is a little more awkard than interacting with very familiar volatile-like capability. Again, coding CAS-like is perfectly usable and solves the problem, I'm just musing openly.

Actually, Peter, I'm starting to really like the idea of you guys supporting volatile read/write in co-ordination with the JBI generated run-time impl. It would be easy to code (for the masses).

from hugecollections-old.

If there is a really good use case for this, we could add it.

With all due respect to using a lock or CAS, I hope you might agree that empowering the user to code like this is a "really good" use case:

//Left PingPong Player
double _coupon = 4.0;
bondOffHeap.setWriteBehindCoupon(_coupon);  // will cross write barrier to /dev/shm
while (_coupon == 4.0) {
       _coupon = bondOffHeap.getReadThroughCoupon();  // will cross read barrier to /dev/shm
}

from hugecollections-old.

Using volatile is full of pit-falls. The problem with volatile is you
can't use multiple operations in a safe manner but it can look like it
works 99.9% of the time.

e.g. you can't do a

• volatile read followed by a volatile write
• two volatile writes
• two volatile reads

without the risk of a race condition.

If you have just one writing thread, you don't want to have multiple
volatile writes to the same object. You only want the last write to be
volatile. There is lots of issues to worry about to trip over a developer.

On 4 June 2014 16:58, Ben Cotton [email protected] wrote:

@peter-lawrey https://github.com/peter-lawrey : That would be awesome
from the vantage point of delivering a super simple user API view. IMHO the
use of CAS-like capability and API is a little more awkard than interacting
with very familiar volatile-like capability. Again, coding CAS-like is
perfectly usable and solves the problem, I'm just musing openly.

Actually, Peter, I'm starting to really like the idea of you guys
supporting volatile read/write in co-ordination with the JBI generated
run-time impl. It would be easy to code (for the masses).

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

from hugecollections-old.

There is lots of issues to worry about to trip over a developer.

Forget it then! :)

from hugecollections-old.

Could OpenHFT it be possible for the user to specify an interface that

bondOffHeap.setWriteBehindCoupon(_coupon); // will cross write barrier to /dev/shm
_coupon = bondOffHeap.getReadThroughCoupon(); // will cross read barrier to /dev/shm

to be coded, but which was implemented by OpenHFT with something other than volatile?

The readThroughXXX() and writeBehindXXX() API being suggested seems like it would be helpful.

from hugecollections-old.

Forget it then!

Wait. I think I am changing my mind (again). I just can't yet abandon this musing: Having an OpenHFT supported generation of readThroughXXX() and writeBehingXXX() impls that could enable a super-simple user API to cross read/write barriers to /dev/shm would indeed be very helpful. If it is at all do-able (without developer pitfals if done with volatile) then it would be very much welcomed here.

from hugecollections-old.

Hi Peter,
I also agree that coding via getReadThroughCoupon(); and setWriteBehindCoupon(); would be easier api then using compareAndSwapCoupon();.

Adding to the api the way Ben suggests allows each PID the option to either get the coupon from /dev/shm/SharedHashMap or from its local on heap reference.

Do you agree?

Thanks
-Xiao

from hugecollections-old.

What I think we need are 3 things:

1. compareAndSwapCoupon(); // giving us Atomic {readThrough; writeBehind} order causality
2. getReadThroughCoupon(); // single operation Read that for multi-pid crosses IPC r/w barriers
3. setWriteBehindCoupon(); // single operattion Write that for multi-pid crosses IPC r/w barriers

2 and 3 are needed in addition to the default JBI getCoupon()/setCoupon() // default do not cross IPC r/w barriers

from hugecollections-old.

To be consistent, it would be

getVolatileCoupon()

setOrderedCoupon();

These would provide the best performance for these memory barrier-ed
operations.

On 6 June 2014 01:17, Ben Cotton [email protected] wrote:

What I think we need are 3 things:

compareAndSwapCoupon(); // giving us Atomic {readThrough; writeBehind}
order causality
2.

getReadThroughCoupon(); // single operation Read that for multi-pid
crosses IPC r/w barriers
3.

setWriteBehindCoupon(); // single operattion Write that for multi-pid
crosses IPC r/w barriers

2 and 3 are needed in addition to the default JBI getCoupon()/setCoupon()
// default do not cross IPC r/w barriers

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

from hugecollections-old.

Hi Peter,

I think this will be a very good addition. OpenHFT providing support for our using both getVolatileCoupon() and setOrderedCoupon() will allow us to pass r/w barrier to /dev/shm for single operation use cases.
If we need to do atomic multi-operation on coupon then absoluately we will use CAS.

Thanks!
-Xiao

from hugecollections-old.

getVolatileCoupon()

setOrderedCoupon();

@peter-lawrey Very nice. Thank you!

@geminigx +1 (emphatically)

from hugecollections-old.

Internal Jira raised JLANG-27 to add volatile getters and ordered writes to code generation so closing this issue.

from hugecollections-old.

Hi guys,

I've implemented this functionality which should now be available on GitHub.

There's a new test VolatileTest
https://github.com/OpenHFT/Java-Lang/blob/master/lang/src/test/java/net/openhft/lang/model/VolatileTest.java
where
you can see the functionality in practice.

In short you need to match

getVolatileXXX()

with

setOrderedXXX()

Works both on and off heap and as well as with arrays.

Please let me have any feedback.

Regards
Daniel

On Fri, Jun 6, 2014 at 4:37 PM, Ben Cotton [email protected] wrote:

getVolatileCoupon()

setOrderedCoupon();

@peter-lawrey https://github.com/peter-lawrey Very nice. Thank you!

@geminigx https://github.com/geminigx +1 (emphatically)

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

from hugecollections-old.

Obvious companions for these methods are addAtomicXxxx and
compareAndSwapXxxx

On 11 June 2014 13:37, danielshaya [email protected] wrote:

Hi guys,

I've implemented this functionality which should now be available on
GitHub.

There's a new test VolatileTest
<
https://github.com/OpenHFT/Java-Lang/blob/master/lang/src/test/java/net/openhft/lang/model/VolatileTest.java>

where
you can see the functionality in practice.

In short you need to match

getVolatileXXX()

with

setOrderedXXX()

Works both on and off heap and as well as with arrays.

Please let me have any feedback.

Regards
Daniel

On Fri, Jun 6, 2014 at 4:37 PM, Ben Cotton [email protected]
wrote:

getVolatileCoupon()

setOrderedCoupon();

@peter-lawrey https://github.com/peter-lawrey Very nice. Thank you!

@geminigx https://github.com/geminigx +1 (emphatically)

—
Reply to this email directly or view it on GitHub
<
https://github.com/OpenHFT/HugeCollections/issues/29#issuecomment-45350739>

.

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

from hugecollections-old.

nice work you guys. thanks!

from hugecollections-old.

Thanks Ben,

To be clear about one thing I just changed in the implementation:

If you want to have a field XXX there are 3 options:

getXXX()
setXXX()

or

getVolatileXXX()
setOrderedXXX()

or

getXXX()
setXXX()
getVolatileXXX()
setOrderedXXX()

On Wed, Jun 11, 2014 at 5:57 PM, Ben Cotton [email protected]
wrote:

nice work you guys. thanks!

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

from hugecollections-old.

which is exactly ideal, Daniel. Thank you.

As was pointed out by Peter earier in this issue, I should not have the expecation for PID1,PID2 lock-free multiple operations on the off-heap volatile reference to preserve orderings ... however I should have the expectation for PID1, PID2 lock-free single operations to work as expected ...

ie. both getVolatileXXX() and setOrderedXXX() will cross r/w barrier to physical /dev/shm/SharedHashMap and -- for single ops -- will provide correct order from both PID1 and PID2 views.

Nicely done Daniel!

Thx,
Ben

from hugecollections-old.

Volatile and ordered provide the same happens before and after guarentees
that volatile reads and writes do.
The ordered write is the same as the AtomicXxxx lazySet operation. It is
faster than a volatile write.
On 11/06/2014 7:47 PM, "Ben Cotton" [email protected] wrote:

which is exactly ideal, Daniel. Thank you.

As was pointed out by Peter earier in this issue, I should not have the
expecation for PID1,PID2 lock-free multiple operations on the off-heap
volatile reference to preserve orderings ... however I should have the
expectation for PID1, PID2 lock-free single operations to work as expected
...

ie. both getVolatileXXX() and setOrderedXXX() will cross r/w barrier to
physical /dev/sh/SharedHashMap and -- for single ops -- will provide
correct order from both PID1 and PID2 views.

Nicely done Daniel!

Thx,
Ben

—
Reply to this email directly or view it on GitHub
#29 (comment)
.

from hugecollections-old.

:-) perfect!

from hugecollections-old.

@ben if it helps we can cut a release build for you ?

On 11 Jun 2014, at 20:51, Ben Cotton [email protected] wrote:

:-) perfect!

—
Reply to this email directly or view it on GitHub.

from hugecollections-old.

@ben - if it helps, we can cut a release build for you ?

On 11 Jun 2014, at 20:51, Ben Cotton [email protected] wrote:

:-) perfect!

—
Reply to this email directly or view it on GitHub.

from hugecollections-old.

Actually, that would be very nice ... I want to be able to demo to certain "jaded" audiences this specific capability (which is ferociously cool ... an intra-PID volatile capability being implemented is unmistakably impressive) ....

from hugecollections-old.