Linked by Thom Holwerda on Fri 28th Oct 2005 11:17 UTC
Permalink for comment 52423
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/25/13 0:45 UTC
Linked by Thom Holwerda on 05/24/13 23:59 UTC
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
More News »
Sponsored Links



Member since:
2005-06-30
It's not just a matter of education, but a matter of tools and practicality. That is to say that it is easier (especially in imperative languages without inherent concurrency primitives) to write single-threaded code and the most practical decision has been to do so in terms of performance and development time given the niche multiprocessor systems have been. When threading has been utilized it has often been so naively, as one might with BeOS or Java wherein lots of threads are spawned for conceptually distinct tasks as a means of providing "fire and forget" asynchronous behavior.
Lots of libraries are not thread-safe, and the naive manner in which one is to make use of such libraries is either to perform locking when calling into them, or to delegate all interaction with the given library to a single thread.
There are a lot of other things involved here, but I can't really address them now.