{"action":"created","issue":{"url":"https://api.github.com/repos/JCTools/JCTools/issues/68","labels_url":"https://api.github.com/repos/JCTools/JCTools/issues/68/labels{/name}","comments_url":"https://api.github.com/repos/JCTools/JCTools/issues/68/comments","events_url":"https://api.github.com/repos/JCTools/JCTools/issues/68/events","html_url":"https://github.com/JCTools/JCTools/pull/68","id":75746935,"number":68,"title":"Transfer array queue","user":{"login":"dorkbox","id":5301521,"avatar_url":"https://avatars.githubusercontent.com/u/5301521?v=3","gravatar_id":"","url":"https://api.github.com/users/dorkbox","html_url":"https://github.com/dorkbox","followers_url":"https://api.github.com/users/dorkbox/followers","following_url":"https://api.github.com/users/dorkbox/following{/other_user}","gists_url":"https://api.github.com/users/dorkbox/gists{/gist_id}","starred_url":"https://api.github.com/users/dorkbox/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dorkbox/subscriptions","organizations_url":"https://api.github.com/users/dorkbox/orgs","repos_url":"https://api.github.com/users/dorkbox/repos","events_url":"https://api.github.com/users/dorkbox/events{/privacy}","received_events_url":"https://api.github.com/users/dorkbox/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":16,"created_at":"2015-05-12T21:33:23Z","updated_at":"2016-01-01T01:55:37Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/JCTools/JCTools/pulls/68","html_url":"https://github.com/JCTools/JCTools/pull/68","diff_url":"https://github.com/JCTools/JCTools/pull/68.diff","patch_url":"https://github.com/JCTools/JCTools/pull/68.patch"},"body":"In Februrary, I found your MpmcArrayQueue, and was very impressed with the performance and lack of generated heap objects (for offer/poll). Being interested in having a similar capability to LinkedTransferQueue (but without any heap allocation), I modified your MpmcArrayQueue to create the \"MpmcTransferArrayQueue\", using a similar technique that Doug Lea used in the LinkedTransferQueue with regards to park/unpark rules. Since one of the requirements for your library is that it can run on java6, I did not depend on the TransferQueue interface -- I'm not sure the best way to resolve this, perhaps to have offer/poll block instead of having transfer/take?? I'm up for whatever suggestions you may have on this topic.\r\n\r\nHere are my handrolled benchmarks for this queue (based on your spsc benchmark code), and I hope that this queue can find a home in your tools. The bechmarks were run on an i7-4700HQ CPU @ 2.40GHz w/ 16gigs of ram, running Linux 3.13.0-49-generic, x86_64. I did not pin the process to CPUs.\r\n\r\nThe non-blocking test results are based on your MpmcArrayQueue implementation, with a small (1024) queue size and a busy-spin on a full queue.\r\n\r\nBlocking | LBQ | LTQ | MTAQ\r\n----------------------|--------|-------|----------\r\n1x1 Threads | 3,7m op/s | 6,3m op/s  | 3,6m op/s\r\n2x2 Threads | 1,9m op/s | 2,4m op/s  | 2,9m op/s\r\n3x3 Threads | 1,4m op/s | 1,8m op/s  | 2,0m op/s\r\n4x4 Threads | 0,8m op/s | 1,4m op/s  | 1,5m op/s\r\n\r\nNon-Blocking | LBQ | LTQ | MTAQ\r\n----------------------|--------|-------|----------\r\n1x1 Threads | 5,8m op/s | 8,1m op/s  | 30,7m op/s\r\n2x2 Threads | 1,4m op/s | 3,4m op/s  | 6,4m op/s\r\n3x3 Threads | 1,2m op/s | 2,3m op/s  | 3,8m op/s\r\n4x4 Threads | 0,8m op/s | 1,8m op/s  | 2,4m op/s"},"comment":{"url":"https://api.github.com/repos/JCTools/JCTools/issues/comments/168273965","html_url":"https://github.com/JCTools/JCTools/pull/68#issuecomment-168273965","issue_url":"https://api.github.com/repos/JCTools/JCTools/issues/68","id":168273965,"user":{"login":"dorkbox","id":5301521,"avatar_url":"https://avatars.githubusercontent.com/u/5301521?v=3","gravatar_id":"","url":"https://api.github.com/users/dorkbox","html_url":"https://github.com/dorkbox","followers_url":"https://api.github.com/users/dorkbox/followers","following_url":"https://api.github.com/users/dorkbox/following{/other_user}","gists_url":"https://api.github.com/users/dorkbox/gists{/gist_id}","starred_url":"https://api.github.com/users/dorkbox/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dorkbox/subscriptions","organizations_url":"https://api.github.com/users/dorkbox/orgs","repos_url":"https://api.github.com/users/dorkbox/repos","events_url":"https://api.github.com/users/dorkbox/events{/privacy}","received_events_url":"https://api.github.com/users/dorkbox/received_events","type":"User","site_admin":false},"created_at":"2016-01-01T01:55:37Z","updated_at":"2016-01-01T01:55:37Z","body":"I've got some initial work done to implement the TransferQueue interface (gist forked here: https://gist.github.com/dorkbox/c755d4b62645c350346e), however I'm not certain the best way to proceed with possible \"bad/corrupt\" indices as a result of tryTransfer (I suppose a solution would be to use a marker and have the next take/poll operation cleanup).\r\n\r\nPreviously, the queue was 'well structured' (either empty or all of a single type) and with the changes I just made [line 386](https://gist.github.com/dorkbox/c755d4b62645c350346e/revisions#diff-ec787c8c727e58cacb1ccba98442796cR386) changes the behaviour of this structure.\r\n\r\n1) tryTransfer can corrupt/invalidate an index (if it fails to transfer), and the worst possible case is a single, blocked consumer and a producer that fills the queue, at which point the queue fails.\r\n"}}