OpenHFT scope of capability re: SHMEntry fields (user JBI supplied) and "barrier" operations

[Cotton-Ben]

what is the currently supported scope of SHMEntry filed barrier operations (across both Threads and PIDs)?

E.g. If I supply a JBI entry of

<T>  MyField;

and signatures

<T> getMyField();
void setMyField(<T> myField);

boolean compareAndSwapMyField(<T>  expected, <T> value);
<T> getVolatileMyField()
void setOrderedMyField(<T> myField);

should we expect that the run-time OpenHFT generated SHMEntry impl class will provide the capability such that the first 2 methods above are non-barrier crossing impls and that last 3 methods are guaranteed to be barrier crossing impls?

is all of this supported currently?

[Cotton-Ben]

Also what is the currently supported type domain set (all primitives + String?) for for this issue?

[peter-lawrey]

you are right however there is addXxxx and addAtomicXxxx. for a complete list of supported options see

https://github.com/OpenHFT/Java-Lang/tree/master/lang/src/main/java/net/openhft/lang/values

On 18 August 2014 15:35, Ben Cotton notifications@github.com wrote:

what is the currently supported scope of SHMEntry filed barrier operations (across both Threads and PIDs)?

E.g. If I supply a JBI entry of

MyField; and signatures getMyField(); void setMyField( myField); boolean compareAndSwapMyField( expected, value); getVolatileMyField() void setOrderedMyField( myField); should we expect that the run-time OpenHFT generated SHMEntry impl class will provide the capability such that the first 2 methods above are non-barrier crossing impls and that last 3 methods are guaranteed to be barrier crossing impls? is all of this supported currently? — Reply to this email directly or view it on GitHub https://github.com/OpenHFT/HugeCollections/issues/40.

[Cotton-Ben]

How high an OpenHFT dev priority "TODO" list is it to support end-users supplying signatures like

<T> getVolatileMyField()
void setOrderedMyField(<T> myField);

in their JBI interfaces (to be passed to net.openhft.lang.model.DataValueClasses API)?

Would it be reasonable to ask that this be supported by EOY 2014?

[peter-lawrey]

Can you check these are not there already?

Obviously we would like you to be one of our paying customers and you will get priority support and extension. On 26/08/2014 5:45 PM, "Ben Cotton" notifications@github.com wrote:

How high an OpenHFT dev priority "TODO" list is it to support end-users supplying signatures like

getVolatileMyField() void setOrderedMyField( myField); in their JBI interfaces (to be passed to net.openhft.lang.model.DataValueClasses API)? Would it be reasonable to ask that this be supported by EOY 2014? — Reply to this email directly or view it on GitHub https://github.com/OpenHFT/HugeCollections/issues/40#issuecomment-53431827 .

[Cotton-Ben]

Can you check these are not there already?

Oh wow. Checking right now ....

Obviously we would like you to be one of our paying customers and you will get priority support and extension.

Coming soon!

[peter-lawrey]

https://github.com/OpenHFT/Java-Lang/blob/master/lang/src/main/java/net/openhft/lang/values/DoubleValue.java On 26/08/2014 5:59 PM, "Ben Cotton" notifications@github.com wrote:

Can you check these are not there already?

Oh wow. Checking right now ....

Obviously we would like you to be one of our paying customers and you will get priority support and extension.

Coming soon!

— Reply to this email directly or view it on GitHub https://github.com/OpenHFT/HugeCollections/issues/40#issuecomment-53434305 .

[Cotton-Ben]

sweet.

[Frank-Bradley]

Forgive me for re-opening this issue ... but I have 1 important question:

Does the support of OpenHFT volatile signatures

<T> getVolatileMyField()
void setOrderedMyField(<T> myField);

(in user supplied JBIs) imply that OpenHFT will do for the r/w ordering (of these kind of fields) across PIDs -- the exact kind of "order bookeeping" that the default Java volatile does (for these kind of fields) across Threads?

[peter-lawrey]

Yes. It provides the appropriate read/write memory barriers. On 29/08/2014 8:17 PM, "Frank-Bradley" notifications@github.com wrote:

Forgive me for re-opening this issue ... but I have 1 important question:

Does the support of OpenHFT volatile signatures

getVolatileMyField() void setOrderedMyField( myField); (in user supplied JBIs) imply that OpenHFT will do for the r/w ordering (of these kind of fields) across PIDs -- the exact kind of "order bookeeping" that the default Java volatile does (for these kind of fields) across Threads? — Reply to this email directly or view it on GitHub https://github.com/OpenHFT/HugeCollections/issues/40#issuecomment-53904747 .