<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Lock-free Java, or better scaling on multi-core systems in Intel® Moderncode for Parallel Architectures</title>
    <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Lock-free-Java-or-better-scaling-on-multi-core-systems/m-p/1037313#M6727</link>
    <description>&lt;P&gt;Everyone these days has to address multi-core issues, or vertical scaling, at least on the server-side of things. And there does not seem to be a general approach, so we end up re-architecting our applications every time we add cores. At the same time, the availability of many-core processors seems to be constrained by the lack of a reasonable software technology to make good use of them.&lt;/P&gt;

&lt;P&gt;Actors seems like a good approach, and allow you to write fast, lock-free code. But large actor-based systems are not robust. Most actor implementations require applications to implement a state machine per actor for determining what messages are to be processed, and maintaining a large number of interacting state machines is well beyond the abilities of most developers. Which is very sad, as throughput of actor-based applications typically scales with the number of cores.&lt;/P&gt;

&lt;P&gt;I've worked on this problem for a number of years now and have developed a simple variation on actors which support non-blocking responses, JActor2. (Request messages are given a call-back which is subsequently called on the actor's own thread to maintain thread safety.) And now it turns out that Microsoft has developed a similar actor model as part of their Orleans project, though their's is .NET based.&lt;/P&gt;

&lt;P&gt;JActor2 is approaching release 1.0, but the project has not been promoted in any way and needs some early adopters. And yes, it is open source and available on github: &amp;lt;a href="https://github.com/laforge49/JActor2#readme"&amp;gt;&lt;SPAN style="line-height: 19.511999130249px;"&gt;&lt;A href="https://github.com/laforge49/JActor2&amp;lt;/a&amp;gt;" target="_blank"&gt;https://github.com/laforge49/JActor2&amp;lt;/a&amp;gt;&lt;/A&gt;;&lt;/SPAN&gt;&lt;/P&gt;

&lt;P&gt;I've gotten this far pretty much on my own, but I doubt that I will get much further without some collaborative efforts. Suggestions?&lt;/P&gt;

&lt;P&gt;Bill LaForge&lt;BR /&gt;
	laforge49@gmail.com&lt;/P&gt;</description>
    <pubDate>Tue, 28 Oct 2014 06:32:40 GMT</pubDate>
    <dc:creator>William_L_2</dc:creator>
    <dc:date>2014-10-28T06:32:40Z</dc:date>
    <item>
      <title>Lock-free Java, or better scaling on multi-core systems</title>
      <link>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Lock-free-Java-or-better-scaling-on-multi-core-systems/m-p/1037313#M6727</link>
      <description>&lt;P&gt;Everyone these days has to address multi-core issues, or vertical scaling, at least on the server-side of things. And there does not seem to be a general approach, so we end up re-architecting our applications every time we add cores. At the same time, the availability of many-core processors seems to be constrained by the lack of a reasonable software technology to make good use of them.&lt;/P&gt;

&lt;P&gt;Actors seems like a good approach, and allow you to write fast, lock-free code. But large actor-based systems are not robust. Most actor implementations require applications to implement a state machine per actor for determining what messages are to be processed, and maintaining a large number of interacting state machines is well beyond the abilities of most developers. Which is very sad, as throughput of actor-based applications typically scales with the number of cores.&lt;/P&gt;

&lt;P&gt;I've worked on this problem for a number of years now and have developed a simple variation on actors which support non-blocking responses, JActor2. (Request messages are given a call-back which is subsequently called on the actor's own thread to maintain thread safety.) And now it turns out that Microsoft has developed a similar actor model as part of their Orleans project, though their's is .NET based.&lt;/P&gt;

&lt;P&gt;JActor2 is approaching release 1.0, but the project has not been promoted in any way and needs some early adopters. And yes, it is open source and available on github: &amp;lt;a href="https://github.com/laforge49/JActor2#readme"&amp;gt;&lt;SPAN style="line-height: 19.511999130249px;"&gt;&lt;A href="https://github.com/laforge49/JActor2&amp;lt;/a&amp;gt;" target="_blank"&gt;https://github.com/laforge49/JActor2&amp;lt;/a&amp;gt;&lt;/A&gt;;&lt;/SPAN&gt;&lt;/P&gt;

&lt;P&gt;I've gotten this far pretty much on my own, but I doubt that I will get much further without some collaborative efforts. Suggestions?&lt;/P&gt;

&lt;P&gt;Bill LaForge&lt;BR /&gt;
	laforge49@gmail.com&lt;/P&gt;</description>
      <pubDate>Tue, 28 Oct 2014 06:32:40 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Moderncode-for-Parallel/Lock-free-Java-or-better-scaling-on-multi-core-systems/m-p/1037313#M6727</guid>
      <dc:creator>William_L_2</dc:creator>
      <dc:date>2014-10-28T06:32:40Z</dc:date>
    </item>
  </channel>
</rss>

