<div>I'm thinking of the engineers here as people who want to build a system and aren't going to understand or safely know how to innovate with something like CAS and are just doing application code, and the scientists as people who are trying to build lock free algorithms and libraries and who do 'get' CAS.</div>
<div> </div>
<div>What I'm saying is that it would be great if these two groups didn't end up split into two completely different ways of doing business. It would be good if the libraries that were created by the scientists were usable by people who were just doing application code.</div>
<div> </div>
<div>E.g. I can use my car without understanding the nanotech that triggers the air bags. I who know little can benefit from the work of geniuses at Ford or Honda who do these incredible things, and they can benefit from having a large market for their product.</div>
<div> </div>
<div>In terms of D, it would be great if the concurrency was expressed in such a way that a person writing a billing application could use data structures implemented via the CAS and similar technologies, and the language had the tools to encapsulate or hide the hard mental-model problems at least for people who don't want to cope with them.</div>
<div> </div>
<div>The threat (if it can be called that) that I see is that we end up with two container libraries, one that is a highly technical piece of research that you need to understand lock-free and wait-free concepts to use, and the one that is a warmed over copy of the Java or STL libs (don't get me wrong, I like the STL most of the time) that the vast majority of consumers use but which doesn't and probably never will benefit from the CAS work.</div>
<div> </div>
<div>Kevin<br><br></div>
<div class="gmail_quote">On Fri, Jan 8, 2010 at 8:03 AM, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:andrei@erdani.com">andrei@erdani.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Nice essay, it just doesn't apply to this case; its converse does. There has been a flurry of theoretical papers defining containers and algorithms relying on DCAS and CASN. They died off because no one has been able to implement those efficiently. The work that endured did it all with CAS.<br>
<br>Andrei<br><br>Kevin Bealer wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">On Thu, Jan 7, 2010 at 11:05 PM, Andrei Alexandrescu <<a href="mailto:andrei@erdani.com" target="_blank">andrei@erdani.com</a> <mailto:<a href="mailto:andrei@erdani.com" target="_blank">andrei@erdani.com</a>>> wrote:<br>
<br> Benjamin Shropshire wrote:<br><br> Andrei Alexandrescu wrote:<br><br> Benjamin Shropshire wrote:<br><br> OTOH that is just another form of the CAS 2 vs CAS 3<br> problem. The system only works if you have the right<br>
abstractions.<br><br><br> What do you mean by CAS 2 and CAS 3?<br><br><br> The problem Kevin cited of their being 1 and 2 word CAS ops, but<br> no 3 word CAS, and if their was a 3 word CAS, then there not<br>
being a 4 word CAS. My point being that you will end up always<br> with some case being just out of reach.<br><br><br> The good news is that CAS is all we need. True, it's not easy...<br><br><br> Andrei<br>
<br> _______________________________________________<br> dmd-concurrency mailing list<br></div> <a href="mailto:dmd-concurrency@puremagic.com" target="_blank">dmd-concurrency@puremagic.com</a> <mailto:<a href="mailto:dmd-concurrency@puremagic.com" target="_blank">dmd-concurrency@puremagic.com</a>>
<div class="im"><br> <a href="http://lists.puremagic.com/mailman/listinfo/dmd-concurrency" target="_blank">http://lists.puremagic.com/mailman/listinfo/dmd-concurrency</a><br><br><br>I think there are two camps here. One is the academic / mathematical camp, that loves to tackle the "it's not easy but theory says it's possible." The second camp is the "what are the best practices?" camp that doesn't own a microscope but looks at trade-offs between known designs. Sort of the 'scientists' and the 'engineers'.<br>
<br>The scientists usually fall into the role of studying fluid dynamics with an eye toward discovering the trick to making the new and experimental but elusive frictionless pipe. The Engineers tend to study building codes and grunge through installing plumbing most of the time, with an eye toward becoming inventors or businessmen. Most of the industry ends up playing the 'engineer' role.<br>
<br>Personally I like tackling the "it's not easy" problems, or at least reading about them and pondering. But what I'd ideally want to make sure is that both camps have a language they can work with. That way, when the scientists discover the new breakthrough in fluid dynamics, it's more likely to be compatible with the toilets and dishwashers that everyone already has.<br>
<br>(Okay, I clearly need sleep.)<br><br>Kevin<br><br><br><br></div>------------------------------------------------------------------------
<div class="im"><br><br>_______________________________________________<br>dmd-concurrency mailing list<br><a href="mailto:dmd-concurrency@puremagic.com" target="_blank">dmd-concurrency@puremagic.com</a><br><a href="http://lists.puremagic.com/mailman/listinfo/dmd-concurrency" target="_blank">http://lists.puremagic.com/mailman/listinfo/dmd-concurrency</a><br>
</div></blockquote>
<div>
<div></div>
<div class="h5">_______________________________________________<br>dmd-concurrency mailing list<br><a href="mailto:dmd-concurrency@puremagic.com" target="_blank">dmd-concurrency@puremagic.com</a><br><a href="http://lists.puremagic.com/mailman/listinfo/dmd-concurrency" target="_blank">http://lists.puremagic.com/mailman/listinfo/dmd-concurrency</a><br>
</div></div></blockquote></div><br>