OpenHFT scope of capability re: SHMEntry fields (user JBI supplied) and "barrier" operations about hugecollections-old HOT 9 CLOSED

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

from hugecollections-old.

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 [email protected] 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
#40.

from hugecollections-old.

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?

from hugecollections-old.

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" [email protected] 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
#40 (comment)
.

from hugecollections-old.

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!

from hugecollections-old.

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" [email protected] 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
#40 (comment)
.

from hugecollections-old.

sweet.

from hugecollections-old.

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?

from hugecollections-old.

Yes. It provides the appropriate read/write memory barriers.
On 29/08/2014 8:17 PM, "Frank-Bradley" [email protected] 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
#40 (comment)
.

from hugecollections-old.