-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PingPong latency test across /dev/shm/SharedHashMap IPC ... #28
Comments
You don't need to redo the assignment unless the key has been deleted. This listener will be notified about all changes. This is intended to On 3 June 2014 15:01, Ben Cotton notifications@github.com wrote:
|
You are 100% correct. I coded the PingPong test wrong. My bad. |
Note: if the key is deleted in another thread, the off heap reference can On 3 June 2014 16:42, Ben Cotton notifications@github.com wrote:
|
@peter-lawrey : many thanks for adding the CAS support for primitve double ... by using CAS operators on my existing off-heap reference( in my central spin-busy wait loop) my tests now run with mean ping-pong latency (across PID1 to PID2 via /dev/shm IPC transport) of 80 nanos (instead of 10 micros). |
The ping-pong latency is perhaps a better indication of what you should get BTW I recommend mounting tmpfs onto /tmp. On 4 June 2014 11:14, Ben Cotton notifications@github.com wrote:
|
TBH, I never "got it" wrt to how that can be any better of an off-heap destination than native /dev/shm .... I still don't get it. Can it really be better? Neither involve any kernel context hops, correct? |
It's better in the sense that /tmp is a natural place for temporary files For testing /tmp makes more sense IMHO, however for production style use On 4 June 2014 11:25, Ben Cotton notifications@github.com wrote:
|
:-), I'm not sure if this is relating to one of the checking's I made, but we try to, when writing unit test point to System.getProperty("java.io.tmpdir") + "/", as this test maybe run on different architecture not just linux. It also is important when run with TeamCity as each agent has its own TMP directory. |
@peter-lawrey +@BoundedBuffer -- true. and all very reasonable considerations, especially from your "Build for all" vantage ... but do know this: we are unbothered wrt to accommodating non-Linux OS providers. :) |
:-), sure, but some of our user still use windows ! :-) |
Ok, we'll behave civilly. |
This very ineresting to me. Would you guys mind if my asking: For ping pong latency between PID1s and PID2s processes, I am looking at the link provided, which BTW does not show the CAS usage in the code pushed to the repo URL. Is it true from that the original problem came from there being a need to do sort of an "IPC synchronized(shm) {/* ...*/}" across the 2 PIDs local views with a main view of the SharedHashMap? If so is it also true that to cross some underlying OpenHFT "IPC read/write barrier" across processes that you must use
but using
will not cross not cross a read barrier to the main memory view of SharedHashMap ? Is what you do with OpenHFT across OS processes and a main view of an off heap SharedHashMap exactly what synchronized/volatile etc. do with acoss JVM ThreadLocal and the Java JMM? @Cotton-Ben please show us your use of CAS to solve the problem (I don't think you pushed what you are describing to the repo url) @peter-lawrey please show us use of SharedMapEventListeners to solve the problem. Sorry for such a long list of an email. but this is very interesting. |
@Frank-Bradley great questions. you go the idea, but I'll let the experts answer in detail. I can't push my Tests right at this moment (give me a few hous) for now, check out this link of how to use
|
Some clients use Windows for development, even if their servers use Linux. On 4 June 2014 11:36, Rob Austin notifications@github.com wrote:
|
You need my version, which Ben has sent.
You can't use synchronize across two processes and as such we don't
Current CAS is supported for int, long and double. float could be added, In this case, CAS is fastest, but if you want a different interaction,
Correct, which is why it didn't work for Ben, and why I replaced it with a
Not exactly. It does a minimal subset e.g. there is no blocking lock On 4 June 2014 12:15, Frank-Bradley notifications@github.com wrote:
|
BTW earlier today I’ve ignored these test net.openhft.collections.fromdocs.pingpong_latency.PingPongPlayerLeft#bondExample because : Connected to the target VM, address: '127.0.0.1:51263', transport: 'socket' java.lang.AssertionError: java.lang.ClassNotFoundException: net.openhft.collections.fromdocs.BondVOInterface$$Native |
The pom for collections needed to be updated, fixed now though they should On 4 June 2014 12:46, Rob Austin notifications@github.com wrote:
|
Thank you. Did you have any code samples or Tests that I could study to learn SharedMapEventListeners API? I've tried looking under test packages and have not seen anything. |
the net.openhft.collections.SharedMapEventListener's, get called when changes occur to the SHM, for example when shm.put(k,v) is called the sharedMapEventListener.onPut(...) will be called The SharedMapEventListener is used by the net.openhft.collections.VanillaSharedReplicatedHashMap.ModificationIterator, but that is a rather complicated example, best look at the logger at net.openhft.collections.SharedMapEventListeners#BYTES_LOGGING for a simple example. |
I have a test that involves 2 Java VM PIDs ping-pong'g the put()/get() of a primitive double by K into a /dev/shm/SharedHashMap.
PID 1 represents a ping pong player positoned on the LEFT side of the table.
PID 2 represents a ping pong player positoned on the RIGHT side of the table.
PID 1 only does a shm.put(K, 4.0);
PID 2 only does a shm.put(K,5.0);
After either PID does its .put() it then spins-busy waiting for the player on the other side to "ping-pong" back their put.
PID 1 -- the player on the left -- must always have its JVM started first for the test to work.
I am getting consistently < 10us latency for this ping-pong latency test.
My 2 questions are these -- on line 38 of each .java at
https://github.com/Cotton-Ben/HugeCollections/tree/master/collections/src/test/java/net/openhft/collections/fromdocs/pingpong_latency
(1) why do I have to do a re-assignment
instead of just re-using the earlier computed off-Heap reference to '_bondEntryV' in the spin-busy waiting loop?
(2) I see that OpenHFT now has a SharedMapEventListeners API ... is this ready? Are there any existing tests I could inspect to affect my learning how to use this API? This API should provide my relief from having to do these spin-busy waiting loops, correct?
The text was updated successfully, but these errors were encountered: