Subj : Re: pthread_create and memory To : comp.programming.threads From : David Schwartz Date : Mon Mar 14 2005 04:32 pm "David Hopwood" wrote in message news:44oZd.59196$Bk7.5979@fe1.news.blueyonder.co.uk... > David Schwartz wrote: >> "David Hopwood" wrote: >>>> No, tasks are primarily for expressing concurrent program structure. >>>> Threads are for keeping CPUs busy or performing asynchronous I/O. >>>> Threads are how you get the work done, not how describe the work. >>>There doesn't need to be any distinction between threads and tasks. >>>The fact that there is such a distinction in most current systems is an >>>implementation artifact, and one that introduces unnecessary complexity. >> I could not disagree more strongly. There definitely does need to be >> such a distinction. Code quality suffers terribly if you don't >> encapsulate the state information that goes along with a task along with >> that task. > Of course state information should be encapsulated, but that doesn't > contradict anything I wrote. The point is that an OS should support a > thread abstraction implemented in such a way that it can scale to large > numbers of simultaneous threads, without requiring concurrent language > implementations to essentially duplicate that functionality. If the OS did support that, then the language *would* duplicate that functionality. I argued that the language must provide that functionality, you are arguing that the thread abstraction should duplicate it. DS .