Я думаю, что и thread1, и thread2 имеют свой «собственный» путь выполнения, и вы не можете заставить их «прерывать» и что-то делать с данными, которые вы создали в другом потоке.Что вы можете сделать, так это то, что вы «планируете» возможность того, что в другом потоке есть что-то готовое, что может потребовать вашего внимания в текущем потоке.Следовательно, и thread1, и thread2 нужен код, который регулярно проверяет, есть ли что-то «готовое» в другом потоке.Если вы планируете делать что-то другое в потоке 1, вам все равно необходимо встроить регулярную проверку / опрос результатов thread2 и наоборот.
Конкретное взаимодействие между потоками может быть реализовано с очередью в каждом направлении.,В .NET 4.0 есть класс ConcurrentQueue для поточно-ориентированной реализации производителя / потребителя.Когда у thread1 есть команда, он должен ставить ее в очередь команд, а thread2 должен регулярно проверять, есть ли ожидающие команды.Когда у thread2 есть готовый результат, он должен поставить его в очередь результатов, в то время как thread1 должен регулярно проверять, есть ли результат, и запускать код обработки соответствующим образом.Более того, если ваше решение именно с этими двумя потоками действительно то, что вам нужно.Однако это зависит от деталей ваших требований (например, что еще должен делать thread1 в то же время, и что означает обработка результата команды, может ли он выполняться параллельно и т. Д.).
Мое предложение будетвыровнять свой дизайн на основе модели производителя / потребителя.Это типичная задача параллелизма, и вы найдете множество объяснений и оптимизированных решений (например, когда потребителю не нужно опрашивать очередь, но он может спать на ручке ожидания, семафоре или какой-либо другой конструкции без использования ЦП и можетбыть разбуженным производителями, если есть что потреблять).В вашем случае вы можете использовать этот шаблон дважды.CommandProducer - это объект, который создает команды и передает CommandConsumer (который может потреблять его, передавая его в последовательную линию).На обратном пути у вас есть CommandResultProducer, который читает последовательную строку и передает результат в CommandResultConsumer, чтобы что-то сделать с результатом.Такое выравнивание вашего кода приведет к более гибкому и понятному решению, и вы даже можете увеличить количество потоков потребителя или производителя, если это окажется практичным.