你是完全正确的。首先要注意的是：你指出的困难是一个很好的证据，证明你的要求几乎没有实际意义，也不应该强加给任何现实生活中的任务。此外，问题的表述是不准确的：在编程中，即使你使用硬件支持的并行计算，也没有什么是同时的。



同样时间，只是为了咯咯笑，（或者，如果你愿意，为了学习/学习目的），我可以展示如何解决这个问题。为简化它，我们假设您只需要两个操作：输入和输出一行。方法如下：

  class  InterlockedConsole {

 object  lockObject =  new   object （）; 

 void  WriteLine（ string   value ）{ lock （lockObject）{System.Console.WriteLine（ value ）; } 

 string  ReadLine（ string   value ）{ lock （lockObject）{ return  System.Console.ReadLine（） ; } 

} 

一个实用的说明：在.NET讨论中，人们常常质疑：为什么不使用锁定（此）{/ * ... * /} ？答案是：是的，它可以完美地工作，但不能提供上述方法的万无一失的质量。它会以同样的方式工作，直到有人（愚蠢的:-)）尝试使用相同的实例锁定其他东西，这可能会产生意想不到的副作用，包括死锁。私人访问 lockObject 有助于避免此类麻烦。



这就是全部。要了解它在多线程情况下的工作原理，请了解锁定和/或互斥：

http：// en.wikipedia.org/wiki/Mutual_exclusion [ ^ ]，

http://msdn.microsoft.com/en-us/ library / c5kehkcz.aspx [ ^ ]。







回复对此答案的评论中的讨论，我对使用仅限控制台的应用程序有一些实用的建议，即使这个应用程序是多线程应用程序，有几个线程使用相同的控制台。这个想法是：一切都可以在一个控制台上运行良好，但你需要排除一件事：交互式输入。



有许多非常好的仅限控制台的应用程序与UI应用程序相比具有许多优势。其中一个好处是，您可以避免大量与UI应用程序相关的手动工作，所有那些在不同项目中的多次点击，因为您可以在批处理文件中使用仅控制台应用程序，并将其与此类其他应用程序结合使用，甚至将它们的输入和输出绑定在一起。



所有这些优秀的应用程序都使用一个简单的模型：输出完成到控制台，但所有输入都是通过命令行参数执行的。从不使用交互式输入，本质上不方便和不可靠。



如果输入的某些部分太大而不适合作为参数，则使用以下方法：一个或多个参数是文件名，因此用户应该在某些文件中提供数据。



我有一个非常易于使用的库命令行解析我的CodeProject文章中提供的解析和命令调用基于枚举的命令行实用程序 [ ^ ] 。



在我的文章中建议再增加一个库。

-SA

I would like to to display output to the user while simultaneously accepting input, I know I can use multithreading and wait on one thread, and output on the other, but then my output looks something like this:

>I am tyThis is text
pinThis is text
 and beiThis is text
ng interThis is text
rupted by thThis is text
e consThis is text
ole outpThis is text
ut

So how do I maintain 1 or 2 steady lines at the bottom that aren't effected by console output?

regards, Jordan

You are perfectly right. First thing to note is: the difficulty you pointed out is a good evidence of the fact that your requirement makes little to no practical sense and should not be imposed for any real-life task. Also, the formulation of the question is inaccurate: in programming, even if you use some parallel computing supported by hardware, nothing is really "simultaneous".

At the same time, just for giggles, (or, if you will, for study/learning purposes), I can show how to resolve this problem. Just to simplify it, let's assume that you need just two operations: input and output of a line. Here is how:

class InterlockedConsole {

    object lockObject = new object();

    void WriteLine(string value) { lock (lockObject) { System.Console.WriteLine(value); } }

    string ReadLine(string value) { lock (lockObject) { return System.Console.ReadLine(); } }

}

One practical note: in .NET discussions, people often question: why not using lock(this) {/* ... */}? The answer is: yes, it will work perfectly, but does not provide fool-proof quality of the approach shown above. It will really work the same way, until someone (foolishly :-)) tries to use the same instance to lock something else, which can have unexpected side effects, including deadlocks. Private access to the lockObject helps to avoid such troubles.

That's all. To understand how it works in multithreading situation, learn about locking and/or mutual exclusion:
http://en.wikipedia.org/wiki/Mutual_exclusion[^],
http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx[^].

[EDIT]

In response to the discussion in the comments to this answer, I have some practical advice on using console-only application even if this application is a multithreading one, with several threads using the same console. The idea is: everything will work well with one console, but you need to exclude just one thing: interactive input.

There are many really good console-only applications which have a number of benefits over UI application. One of such benefits is that you can avoid a lot of manual work associated with UI applications, all those multiple clicks in different items, because you can use the console-only applications in a batch file, and combine it with other applications of this sort, even bind together their inputs and outputs.

All such good application uses one simple model: output is done to console, but all input is performed via the command line parameters. Interactive input, inherently inconvenient and unreliable, is never used.

In case some parts of input are too big to be suitable as a parameter, the following approach is used: one or more of the parameters are file names, so the user should provide data in some file(s).

I have a very easy-to-use library for command line parsing parsing and command invocation available in my CodeProject article Enumeration-based Command Line Utility[^].

One more library is recommended in the text of my article.

—SA