Talk:Concurrent computing: Difference between revisions
→What are "concurrent threads"?: new section
m (moved Talk:Simple concurrent actions to Talk:Concurrent computing) |
(→What are "concurrent threads"?: new section) |
||
Line 15:
::Interesting. I believe it is not an issue since ''writing'' to a stream should be ''atomically'' done, or done in a thread-safe way. The worst that can happen is messing up output, but race conditions or deadlocks or any other bad thing should not occur (at least, if messing up output is not a bad thing! EnRosejotCotayde?!) Consider that the same ''stream'' (stdout) can be ''transparently'' used by several processes (e.g. I am running Kate editor from the same shell I use to compile code, so sometimes stderr of Kate is intermixed with stdout and stderr of other tasks) --[[User:ShinTakezou|ShinTakezou]] 18:50, 17 December 2008 (UTC)
::Hm, maybe I am wrong, since for different processes the ''file'' descriptor is replicated; nonetheless they are always attached to the same terminal, and I am still thinking that race conditions are not possible. --[[User:ShinTakezou|ShinTakezou]] 19:01, 17 December 2008 (UTC)
== What are "concurrent threads"? ==
Conceptually speaking, unless you have multiple CPUs, there cab be only one "thread" that is executing at any one time. This suggests a possible approach for implementing this task in languages which do not "support threading": One could implement a simplistic thread scheduler, and then use that to implement the task.
Consider also languages which support concurrent syntax without necessarily haven gotten around to implementing support for dispatching across multiple CPUs.
This leaves me wondering, what does this task specification really mean, in a language agnostic sense? --[[User:Rdm|Rdm]] 15:38, 24 November 2010 (UTC)
| |||