как работать с позицией в потоке C #
Во всей документации для свойства position в потоке говорится:
- При переопределении в производном классе получает или устанавливает позицию в текущем потоке .
- Свойство Position не отслеживает количество байтов из потока, которые были использованы, пропущены или и то, и другое.
Вот и все. Итак, мы довольно ясно понимаем, о чем он нам не говорит, но мне бы очень хотелось знать, что на самом деле означает . Какова «позиция» для ? Зачем нам его изменять или читать? Если мы его изменим - что произойдет?
В практическом примере у меня есть поток, в который периодически записывается, и у меня есть поток, который пытается читать из него (в идеале как можно скорее).
Из чтения многих Поэтому я сбрасываю поле position на ноль, чтобы начать чтение.Как только это будет сделано:
- Влияет ли это на то, где писатель этого потока будет пытаться поместить данные? Нужно ли мне самому отслеживать последнюю позицию записи? (то есть, если я установил нулевое положение для чтения, не начнет ли писатель перезаписывать все, начиная с первого байта?)
- Если да, нужен ли мне семафор / блокировка вокруг этого поля «позиция» (возможно, создание подкласса?) из-за того, что к нему обращаются два моих потока?
- Если я не обрабатываю это свойство, может ли писатель просто переполнять буфер?
Возможно, я не понимаю сам поток - я рассматриваю его как канал FIFO : вставлять данные с одного конца и высасывать их с другого. Если это не , как это, то должен ли я продолжать копировать данные после моего последнего чтения (т. е. из позиции 0x84 on) обратно в начало моего буфера?
Я серьезно пытался исследовать все это довольно долгое время, но я новичок в .NET. Возможно, у Streams долгая, гордая (недокументированная) история, которую все остальные безоговорочно понимают. Но для новичка это все равно, что прочитать инструкцию к своей машине и узнать:
Педаль акселератора влияет на объем топлива и воздуха, подаваемого в топливные форсунки. Это не влияет на громкость развлекательной системы или давление воздуха в любой из шин, если она установлена.
Технически верно, но серьезно, мы хотим знать, что если мы разнесем его на пол, вы пойдете быстрее ..
РЕДАКТИРОВАТЬ - Большая картинка
У меня есть данные, которые поступают либо из последовательного порта, сокета или файла и иметь поток, который сидит там, ожидая новых данных и записывая их в один или несколько потоков - все идентично.
К одному из этих потоков я могу получить доступ из сеанса telnet с другого компьютера, и все работает нормально.
Проблема, с которой я столкнулся, заключается в анализе данных в коде той же программы (в другом из дублированных потоков). Я копирую данные в MemoryStream, и у меня есть поток, который будет сидеть, расшифровывать данные и передавать их обратно в пользовательский интерфейс.
Этот поток выполняет dataStream.BeginRead () в свой собственный буфер, который возвращает некоторое (?) количество данных до, но не более аргумента count . После того, как я разобрался с тем, что получил от BeginRead , я копирую оставшиеся данные (от конца моей точки чтения до конца потока) в начало моего буфера, так что он выиграл » t переполнение.
На этом этапе, поскольку и запись, и чтение являются асинхронными, я не знаю, могу ли я изменить позицию (поскольку это «курсор» - спасибо Джону). Даже если отправить сообщение в другой поток, чтобы сказать, что я только что прочитал 28 байтов или что-то еще - он не будет знать , какие 28 байтов они были, и не будет знать, как сбросить его курсор. / [position].
Я не создавал подклассы для потоков - я только что создал MemoryStream и передал его потоку, который дублирует данные в любые потоки, которые требуются.
Все это кажется слишком сложным, чтобы быть правильным способом - я просто не могу найти простой пример, который я могу изменить по мере необходимости ..
Как еще люди справляются с длительным спорадическим потоком данных, который необходимо отправить в какую-то другую задачу, выполнение которой не происходит мгновенно?
РЕДАКТИРОВАТЬ: вероятное решение
При попытке написать оболочку Stream вокруг очереди из-за информации в ответах я наткнулся на это сообщение Стивена Туба.
Он написал BlockingStream и объясняет:
Большинство потоков в .NET Framework не являются потокобезопасными, что означает, что несколько потоков не могут безопасно получить доступ к экземпляру поток одновременно, и большинство потоков поддерживают единственную позицию, в которой произойдет следующее чтение или запись. BlockingStream, с другой стороны, является потокобезопасным и, в некотором смысле, неявно поддерживает две позиции, хотя ни одна из них не отображается в виде числового значения для пользователя типа.BlockingStream работает, поддерживая внутреннюю очередь буферов данных, записанных в него. Когда данные записываются в поток, записанный буфер ставится в очередь. Когда данные считываются из потока, буфер удаляется из очереди в порядке FIFO, и данные в нем возвращаются вызывающей стороне. В этом смысле есть позиция в потоке, в которой произойдет следующая запись, и позиция, в которой произойдет следующее чтение.
Кажется, именно то, что я искал - так что спасибо тем, кто отвечает, ребята, я нашел это только из ваших ответов.