However there are MANY cases where execution order does not matter. These are the BEST cases for threads.<div>In most of these cases there is a long list of work to be done, none of which references any of the other work. Some examples include brute force solving of complex hashing functions,</div>
<div>downloading of large lists of files or basically any time you have lots of 'slow' work that you know all the details about in advance. </div><div>In these cases all you have are self-contained threads that need to pull from one list and possibly push answers to another. </div>
<div><br></div><div>Tell me then why any of what you have said is relevant. In fact in cases this this the use of CriticalSections would be sensible and would not cause 'tons of wait' as you have all your worker threads off doing things 99% of the time.  </div>
<div><br></div><div>Also If you have lots of code that requires things to happen in specific orders, I think you need to re-evaluate your use of threads. Attempts to make things that require synchronous processing or order, suddenly asynchronous is just stupid and fraught with issues. Most of the time you should find a 'string of tasks' that can be done asynchronously, this is what you get threads to do. IF all the processing you have requires specific execution order then don't use threads.. The other possibility is that you are just doing it wrong.  </div>
<div><br></div><div>I don't see how the idea of Execution order is that hard, it should be seen like giving tasks to 100's of people when organising a large event or something. I think most of the 'difficulty' for programmers with multi-threading is understanding how to delegate. </div>
<div><br></div><div><br><div class="gmail_quote">On Tue, Jun 28, 2011 at 8:31 AM, Andrew Brunner <span dir="ltr"><<a href="mailto:andrew.t.brunner@gmail.com">andrew.t.brunner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Mon, Jun 27, 2011 at 2:51 PM, Hans-Peter Diettrich<br>
<<a href="mailto:DrDiettrich1@aol.com">DrDiettrich1@aol.com</a>> wrote:<br>
>> Absolutely incorrect.<br>
><br>
> Why?<br>
><br>
<br>
Two reasons.<br>
<br>
1.) Visibility.  A critical section does not particularly protect<br>
visibility as with 2 threads accessing a piece of memory.<br>
<br>
2.) Execution Order.  A critical section does not protect or ensure<br>
that code will be executed in any particular order.  This is where<br>
multi-core/multi-threaded systems vs theory get extremely complicated.<br>
 AMD vs Intel.  Kernels Linux vs Windows.  The only way to make sure<br>
you can get code in proper order with regard to memory assignments (<br>
specifically variables) is to use Interlocked methods.  This is why<br>
they were designed.<br>
<br>
The analogy would be like using a wisk vs a commerical grade mixer to<br>
scramble your eggs.  Use the commercial grade mixer in this case<br>
(CriticalSection) and expect a high cost of use and tons of wait<br>
states - which translates into poor benchmarks.<br>
<div><div></div><div class="h5"><br>
--<br>
_______________________________________________<br>
Lazarus mailing list<br>
<a href="mailto:Lazarus@lists.lazarus.freepascal.org">Lazarus@lists.lazarus.freepascal.org</a><br>
<a href="http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus" target="_blank">http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus</a><br>
</div></div></blockquote></div><br></div>