Это проблема 32-битного процесса. Всего 4 Гб из них 2 Гб ОС, вторые 2 Гб проге, в них и .Net и твои данные.

В твоем случае лучше BitArray взять. Тут будет 1 бит - одно значение, т.е. все положительные значения Int32 (до 2^31) займут 256 Мб (2^28)

AR®Я бы взял BitArray, но он не потокобезопасен.
Используй блокировки lock() . Быстрее будет чем с ConcurrentDictionary

Если еще быстрее надо, то взять массив Int32[], прописать логику работы с битами, а для чтения/записи использовать Interlocked функции.

AR®работает правильно как с ConcurrentDictionary без принятия специальных мер по блокировке.
Это твое "правильно" те еще грабли. Когда проблемы возникнут - исключений не будет, просто получишь неправильный результат своего расчета.

Т.к. работа с битами происходит через байты, то вполне возможна такая ситуация когда два потока одномоментно захотят установить разные биты в одном байте.
Например это может произойти так
Поток 1Поток 2Прочитал байтПрочитал байтУстановил бит 3Установил бит 5Записал байтЗаписал байт
в итоге то что сделал Поток 1 будет затерто, т.е. бит 3 не будет установлен.
Поэтому блокировки доступа при записи обязательны. При чтении можно не блокировать доступ, но тогда перед записью, внутри блокировки делать повторное чтение.

AR®bool[] вынудил прибегнуть к ConcurrentDictionary, при числе потоков от 4 до 32.
bool[] ничем не отличается от BitArray, разве что в 8 раз больше места требуется.
AR®Прироста скорости по сравнению с ConcurrentDictionary пока не обнаружил.
Можно не заметить если на работу с массивом уходит незначительная часть времени работы проги. Например если это 1%, то даже если в 10 раз ускорилось, то ускорение всего 0,9% от общего времени.

AR®Скажите, будет ли в общем случае достаточно брать в lock(){ } операции записи в массив?
Думаю да, но на 100% не уверен.

Лучше все обращения обернуть. Сделай класс-обертку, два метода Read() и Write(). В них пропиши c lock(). Как понял на общем времени работы твоего кода это особо не скажется, но надежность будет гарантированная.

AR®Скажите, будет ли в общем случае достаточно брать в lock(){ } операции записи в массив?
Посмотрел исходник bitarray.cs
Чтение


Думаю без lock() можно читать. Нечему тут глючить при многопоточности.

AR®С lock остаётся только преимущество в памяти (что для моего случая важно). Видимо потому, что блокировка накладывается на весь массив, а не на отдельный бит :)
Блокировка вообще не накладывается. Это просто флаг, первый поток установил и что-то делает, второй, при попытке его установить - останавливается и ждет пока первый не снимет.

Можешь разделить массив на условные блоки (0-1048575, 1048576-... и т.д.) и использовать отдельный объект для блокировки каждого блока. Только учти что блоки массива, за который отвечает одна блокировка, должны быть кратны 32. Т.к. внутри BitArray используется Int32[].

AR®Интересно, а можно ли скомпилировать 64-битное приложение на 32-битном компе?
Скомпилировать можно, но оно не запустится.

AR®С lock остаётся только преимущество в памяти (что для моего случая важно). Видимо потому, что блокировка накладывается на весь массив, а не на отдельный бит :)
Можно Interlocked.CompareExchange() вместо lock(). Так вообще без блокировок. Только класс придется свой делать.

AR®Хотелось бы, чтобы оно запустилось на 64-битной ОС, где памяти стоит побольше, и не будет ограничения как для 32-битного процесса.
Если по-простому: Внутри EXE находится IL-код, по месту запуска он может заработать и как х32 и как x64 без перекомпиляций. Можно явно задать чтобы везде одинаково было. Это в заголовке EXE указывается. Подробно у Рихтера расписано.
Как в студии настроить не знаю, а с командной строки так компилировать


без указания платформы, тогда на x32 компе запустится как x32, на x64 как x64

Только не надейся что при x64 у тебя не выскочит OutOfMemory. Там тоже ограничения есть, виндовс как-то ограничивает чтобы приложение всю память не отъело.
И еще такой момент: x64 работает на ~30% медленнее чем х32.

AR®Спасибо за класс.
Dima TТолько не надейся что при x64 у тебя не выскочит OutOfMemory. Там тоже ограничения есть, виндовс как-то ограничивает чтобы приложение всю память не отъело.


Очень интересно, каковы они и где установливаются. Работает же как-то, ну например, SQL Server, который берёт, сколько ему нужно.
Специально не интересовался, случайно нигде не попадалось, так что гугл в помощь если интересно. Наверно есть какое-нибудь WinAPI чтобы попросить ОС дать больше чем по умолчанию.
AR®Dima TИ еще такой момент: x64 работает на ~30% медленнее чем х32.
Это с лихвой компенсировалось бы отсутствием ограничений на выделяемую процессу память. В процессе экспериментов я попутно выяснил, что, например, BitArray даёт время работы раза ~в 4 больше, чем bool[ ] (он используется у меня в каждом отдельном потоке).
bool[ ] быстрее, т.к. там просто получение байта из массива (m_array[index]), без всяких доп.расчетов (m_array[index / 32] & (1 << (index % 32)))
AR®И вот ещё интересный вопрос. Если делать свой класс, как ваш ConcurrentBitArray, с точки зрения минимизации времени работы, что лучше взять за основу: Int32, или более короткие Int16, byte, или наоборот, длинный Int64 ?
Int16 и byte отпадают Interlocked.CompareExchange() перегружен только для Int32 и Int64. Работа с Int64 под x32 медленнее. В принципе можешь затестить как оно будет в твоей задаче.