Доступ к стриму из разных потоков

@Villain512 · Регистрация: 19.01.2013

Студворк — интернет-сервис помощи студентам

Задача такая, имеем мемористрим, в одном потоке постоянно пишем его. В другом потоке необходимо по запросу считывать весь поток в байтаррай, но чтобы позиция при записи не сместилась. Как решение вижу применение монитора, но хотелось бы услышать другие предложения.

@danrusm · 24.01.2013, 13:42

Зачем такие жертвы, останавливай запись потока, считывай, потом разблокируй, сделай всё на булевых флагах.
В зависимости от приоритета переключай запись и чтение, скажем если приоритет считывания выше, значит он устанавливает false на запись и считывает, потом разрешает запись. А объекты ядра оставьте для худших вариантов.

@Villain512 · 24.01.2013, 13:44 **[ТС]**

в разных потоках говорю. как я просто так возьму и остановлю этот процесс в другом потоке.

@turbanoff · 24.01.2013, 14:12

Сообщение от danrusm

Зачем такие жертвы, останавливай запись потока, считывай, потом разблокируй, сделай всё на булевых флагах.
В зависимости от приоритета переключай запись и чтение, скажем если приоритет считывания выше, значит он устанавливает false на запись и считывает, потом разрешает запись. А объекты ядра оставьте для худших вариантов.

Какой странный плохой совет. А если поток который читает, проверит флаг и сразу после этого второй поток скинет его. Получится, что stream будет доступен обоим потокам.

Используйте синхронизацию (lock). Если думаете, что будет медленно - замерьте производительность.

@Villain512 · 24.01.2013, 14:14 **[ТС]**

Дык я и предложил лок использовать, он же монитор. Но меня производительность смутила немного. Ладно сделаю как и хотел.

@turbanoff · 24.01.2013, 14:32

Сообщение от Villain512

Но меня производительность смутила немного.

Поэтому я и говорю - чтобы не смущала, замерьте производительность. До и после.

@Villain512 · 24.01.2013, 21:18 **[ТС]**

задача несколько изменилась. Скорость записи то не страдает, а вот скорость чтения и занимаемая память страдает.

Нужно чтобы данные писались не в стрим а добавлялись в массив байт без копирования его самого. чтобы я мог в любой момент считать оттуда данные безовсяких преобразований. Сейчас используется аррай.копи, но меня терзают сильные сомнения по его поводу (не проверял работу с большими объемами данных).

Как можно добавлять данные в массив фиксированной длинны (именно byte[], всякие там листы не предлагать, никакие преобразования не разрешены, ибо я в теории могу по 10000раз считать его во время добавления туда данных), чтобы небыло лишнего потребления памяти или ненужных вычислений?

@danrusm · 25.01.2013, 15:14

Я предложил как вариант.
Если потоков всего два, пишущий и читающий, вообще не вижу проблем в моём варианте, флагами управляет читающий поток. Ну моё дело предложить, по мне объект ядра так вообще не нужен. Хотя товарищь Villain512 так смело оперирует словами процесс и поток, что меня это смущает.
А данные без разрыва добавлять нельзя, только в случае заранее зарезервированного объёма памяти.

@Villain512 · 25.01.2013, 15:20 **[ТС]**

под процессом имеется ввиду не процесс самого приложения, а просто слово процесс как оно есть

Если один поток читает а второй пишет то у них будет конфликт, если не синхронизовать их работу локом.

Мемори стрим по причине потребления памяти мне не подходит. допустим я скачиваю файл размером 2 гига, чтобы им воспользоваться придется считать его из стрима и поместить в массив байт. а это еще 2 гига и затраты процессора. Необходимо использовать общий массив байт и как то без затрат добавлять в него. См. выше.

@danrusm · 25.01.2013, 20:41

Если я понял правильно, вы хотите использовать общую память для загрузки в неё информации и параллельного чтения.
В таком случае вообще не вижу причин для синхронизации, синхронизация нужна для двух пишущих потоков, а чтение можно осуществлять из множества потоков без какой либо синхронизации. Тут просто надо публичный счётчик, в котором будет отображаться длинна записанных данных, чтоб в обработку читающего потока не попала хрень.
Если предоставите больше информации о работе приложения, можно будет более предметно обсуждать.

Добавлено через 6 минут
Если у вас происходит фрагментная запись по мере закачки, можно очень даже хорошо пристроить List<byte[]> , скажем каждые 10 мегабайт скачаного будут скидываться в лист, а читающий поток будет получать доступ и будет знать где и что взять, но опять же синхронизация не нужна. При желании даже на винт можно скидывать частями по мере обработки.

@Villain512 · 25.01.2013, 20:46 **[ТС]**

синхронизация согласно первоначальной задумке была нужна для того чтобы чтение и запись не были одновременно, чтобы после чтения я мог вернуть указатель на место.

List<byte[]>

И как интересно это решит проболему, если память все равно будет потребляться вдвойне, когда я захочу получить из этого листа целый массив байт.

Если предоставите больше информации о работе приложения, можно будет более предметно обсуждать.

Это не приложение а класс отдельный, для работы в любом приложении.

Тут просто надо публичный счётчик, в котором будет отображаться длинна записанных данных, чтоб в обработку читающего потока не попала хрень.

Хрень какаято)

Единственный разумный выход который пришел мне в голову это писать данные через прямой доступ к памяти в исходный массив байт (если конечно нельзя его изменить размер динамически без потребления дополнительной памяти), но это как то дико и опять же стоит вопрос о производительности.

@danrusm · 26.01.2013, 07:44

Уважаемый Villain512, только вы знаете как собираетесь обрабатывать данные, я вас просто убеждаю что нет необходимости синхронизации читающего и пишущего потока, нужно только договориться о размере. Если вы не хотите фрагментировать данные, резервируйте пространство заранее, ведь речь шла о скачивании файла, не надо буквально всё понимать, адаптируйте под свои нужды на здоровье.
Кстати по поводу получения целого массива, собирайте его постепенно, я вам предложил лист, лишь для того чтоб не замораживать резервируемое пространство для всего файла. В общем я вижу вы сами понимаете что вам делать.

@Villain512 · 26.01.2013, 10:18 **[ТС]**

Ну про создание массива заранее это понятно если размер известен. но на выходе то я должен получить массив текущего размера, а не общий

. Вдобавок есть такая штука как чанкед транспорт энкодинг. Там нету макс размера, а есть только размер текущего блока.

Чтобы пересобрать массив из чего угодно так или иначе придется потреблять память в двойном размере. Поэтому ненадо ничего пересобирать.

@danrusm · 26.01.2013, 11:30

Мне кажется, цель для вашего класса излишне абстрактная, определите её для себя чётко, хотя вам опять же виднее.

@Villain512 · 26.01.2013, 11:51 **[ТС]**

Да нету ничего абстрактного. задача вполне ясна. нужно писать данные в массив байт и должна быть возможность их считывания в любой момент оттуда, безо всяких доп потреблейний памяти и преобразований.

Это необходимая мне функция в библиотеке, позволяющая прервать соединение при получении необходимой инфы. допустим я качаю файл 1гб а мне требуется оттуда определенный кусок вначале. не стану же я ждать пока весь скачается

.

@danrusm · 26.01.2013, 14:19

Да какие проблемы, качайте в неразрывный массив, расположенный в заранее зарезервированном пространстве необходимого размера, и счётчик скачаного сделайте, как я уже говорил, чтоб не считывать то, чего ещё нет. А синхронизацией тут и не пахнет.

@Villain512 · 26.01.2013, 14:21 **[ТС]**

Мне нужен на выходе массив который имеет размер соответствующий размеру скаченного. Вдобавок опять напомню про чанкед транспорт энкодинг.

Новые блоги и статьи Все статьи Все блоги /
Использование SDL3-callbacks вместо функции main() на Android, Desktop и WebAssembly 8Observer8 24.01.2026 Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а привычная функция main(). . .	моя боль iceja 24.01.2026 Выложила интерполяцию кубическими сплайнами www. iceja. net REST сервисы временно не работают, только через Web. Написала за 56 рабочих часов этот сайт с нуля. При помощи perplexity. ai PRO , при. . .	Модель сукцессии микоризы anaschu 24.01.2026 Решили писать научную статью с неким РОманом	http://iceja.net/ математические сервисы iceja 20.01.2026 Обновила свой сайт http:/ / iceja. net/ , приделала Fast Fourier Transform экстраполяцию сигналов. Однако предсказывает далеко не каждый сигнал (см ограничения http:/ / iceja. net/ fourier/ docs ). Также. . .
http://iceja.net/ сервер решения полиномов iceja 18.01.2026 Выкатила http:/ / iceja. net/ сервер решения полиномов (находит действительные корни полиномов методом Штурма). На сайте документация по API, но скажу прямо VPS слабенький и 200 000 полиномов. . .	Расчёт переходных процессов в цепи постоянного тока igorrr37 16.01.2026 / * Дана цепь(не выше 3-го порядка) постоянного тока с элементами R, L, C, k(ключ), U, E, J. Программа находит переходные токи и напряжения на элементах схемы классическим методом(1 и 2 з-ны. . .	Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/

@Villain512 2 / 2 / 1 Регистрация: 19.01.2013 Сообщений: 155

	Доступ к стриму из разных потоков 24.01.2013, 10:14. Показов 2270. Ответов 16 Метки нет (Все метки) Задача такая, имеем мемористрим, в одном потоке постоянно пишем его. В другом потоке необходимо по запросу считывать весь поток в байтаррай, но чтобы позиция при записи не сместилась. Как решение вижу применение монитора, но хотелось бы услышать другие предложения. 0

@danrusm 49 / 49 / 2 Регистрация: 17.07.2011 Сообщений: 318
	24.01.2013, 13:42
	Зачем такие жертвы, останавливай запись потока, считывай, потом разблокируй, сделай всё на булевых флагах. В зависимости от приоритета переключай запись и чтение, скажем если приоритет считывания выше, значит он устанавливает false на запись и считывает, потом разрешает запись. А объекты ядра оставьте для худших вариантов. 0

@Villain512 2 / 2 / 1 Регистрация: 19.01.2013 Сообщений: 155
	24.01.2013, 13:44 [ТС]
	в разных потоках говорю. как я просто так возьму и остановлю этот процесс в другом потоке. 0

@Villain512 2 / 2 / 1 Регистрация: 19.01.2013 Сообщений: 155
	24.01.2013, 14:14 [ТС]
	Дык я и предложил лок использовать, он же монитор. Но меня производительность смутила немного. Ладно сделаю как и хотел. 0

@Villain512 2 / 2 / 1 Регистрация: 19.01.2013 Сообщений: 155
	24.01.2013, 21:18 [ТС]
	задача несколько изменилась. Скорость записи то не страдает, а вот скорость чтения и занимаемая память страдает. Нужно чтобы данные писались не в стрим а добавлялись в массив байт без копирования его самого. чтобы я мог в любой момент считать оттуда данные безовсяких преобразований. Сейчас используется аррай.копи, но меня терзают сильные сомнения по его поводу (не проверял работу с большими объемами данных). Как можно добавлять данные в массив фиксированной длинны (именно byte[], всякие там листы не предлагать, никакие преобразования не разрешены, ибо я в теории могу по 10000раз считать его во время добавления туда данных), чтобы небыло лишнего потребления памяти или ненужных вычислений? 0

@danrusm 49 / 49 / 2 Регистрация: 17.07.2011 Сообщений: 318
	25.01.2013, 15:14
	Я предложил как вариант. Если потоков всего два, пишущий и читающий, вообще не вижу проблем в моём варианте, флагами управляет читающий поток. Ну моё дело предложить, по мне объект ядра так вообще не нужен. Хотя товарищь Villain512 так смело оперирует словами процесс и поток, что меня это смущает. А данные без разрыва добавлять нельзя, только в случае заранее зарезервированного объёма памяти. 0

@Villain512 2 / 2 / 1 Регистрация: 19.01.2013 Сообщений: 155
	25.01.2013, 15:20 [ТС]
	под процессом имеется ввиду не процесс самого приложения, а просто слово процесс как оно есть Если один поток читает а второй пишет то у них будет конфликт, если не синхронизовать их работу локом. Мемори стрим по причине потребления памяти мне не подходит. допустим я скачиваю файл размером 2 гига, чтобы им воспользоваться придется считать его из стрима и поместить в массив байт. а это еще 2 гига и затраты процессора. Необходимо использовать общий массив байт и как то без затрат добавлять в него. См. выше. 0

@danrusm 49 / 49 / 2 Регистрация: 17.07.2011 Сообщений: 318
	25.01.2013, 20:41
	Если я понял правильно, вы хотите использовать общую память для загрузки в неё информации и параллельного чтения. В таком случае вообще не вижу причин для синхронизации, синхронизация нужна для двух пишущих потоков, а чтение можно осуществлять из множества потоков без какой либо синхронизации. Тут просто надо публичный счётчик, в котором будет отображаться длинна записанных данных, чтоб в обработку читающего потока не попала хрень. Если предоставите больше информации о работе приложения, можно будет более предметно обсуждать. Добавлено через 6 минут Если у вас происходит фрагментная запись по мере закачки, можно очень даже хорошо пристроить List<byte[]> , скажем каждые 10 мегабайт скачаного будут скидываться в лист, а читающий поток будет получать доступ и будет знать где и что взять, но опять же синхронизация не нужна. При желании даже на винт можно скидывать частями по мере обработки. 0

@danrusm 49 / 49 / 2 Регистрация: 17.07.2011 Сообщений: 318
	26.01.2013, 07:44
	Уважаемый Villain512, только вы знаете как собираетесь обрабатывать данные, я вас просто убеждаю что нет необходимости синхронизации читающего и пишущего потока, нужно только договориться о размере. Если вы не хотите фрагментировать данные, резервируйте пространство заранее, ведь речь шла о скачивании файла, не надо буквально всё понимать, адаптируйте под свои нужды на здоровье. Кстати по поводу получения целого массива, собирайте его постепенно, я вам предложил лист, лишь для того чтоб не замораживать резервируемое пространство для всего файла. В общем я вижу вы сами понимаете что вам делать. 0

@Villain512 2 / 2 / 1 Регистрация: 19.01.2013 Сообщений: 155
	26.01.2013, 10:18 [ТС]
	Ну про создание массива заранее это понятно если размер известен. но на выходе то я должен получить массив текущего размера, а не общий . Вдобавок есть такая штука как чанкед транспорт энкодинг. Там нету макс размера, а есть только размер текущего блока. Чтобы пересобрать массив из чего угодно так или иначе придется потреблять память в двойном размере. Поэтому ненадо ничего пересобирать. 0

@danrusm 49 / 49 / 2 Регистрация: 17.07.2011 Сообщений: 318
	26.01.2013, 11:30
	Мне кажется, цель для вашего класса излишне абстрактная, определите её для себя чётко, хотя вам опять же виднее. 0

@Villain512 2 / 2 / 1 Регистрация: 19.01.2013 Сообщений: 155
	26.01.2013, 11:51 [ТС]
	Да нету ничего абстрактного. задача вполне ясна. нужно писать данные в массив байт и должна быть возможность их считывания в любой момент оттуда, безо всяких доп потреблейний памяти и преобразований. Это необходимая мне функция в библиотеке, позволяющая прервать соединение при получении необходимой инфы. допустим я качаю файл 1гб а мне требуется оттуда определенный кусок вначале. не стану же я ждать пока весь скачается . 0

@danrusm 49 / 49 / 2 Регистрация: 17.07.2011 Сообщений: 318
	26.01.2013, 14:19
	Да какие проблемы, качайте в неразрывный массив, расположенный в заранее зарезервированном пространстве необходимого размера, и счётчик скачаного сделайте, как я уже говорил, чтоб не считывать то, чего ещё нет. А синхронизацией тут и не пахнет. 0

@Villain512 2 / 2 / 1 Регистрация: 19.01.2013 Сообщений: 155
	26.01.2013, 14:21 [ТС]
	Мне нужен на выходе массив который имеет размер соответствующий размеру скаченного. Вдобавок опять напомню про чанкед транспорт энкодинг. 0