Параллельный доступ для чтения на интервале [] массив: действительно ли это безопасно? Это быстро?
В Java это будет выглядеть как NullPointerException , вы не получаете такого рода ошибки в C, но это также связано с ответственностью. Отсылка нулевого указателя в C (как вы это сделали) может отвечать разными способами. Как уже было сказано в комментариях, вам нужно выделить указатель data.
complex *data = malloc(sizeof(complex));
И вам также следует освободить память, выделенную с помощью malloc, поэтому в конце кода перед возвратом состояния вашей программы в ОС (чего вы не сделали) вы должны сделать: [ 1112]
free(data);
Я не уверен в том, как работает ваш csvread, но он может не работать, используя не что иное, как массив сложных структур. Приведенный ниже код выделяет 10 комплексных чисел, инициализирующих их все, внутри функции csvread вам, возможно, придется внести некоторые изменения, чтобы перебрать их, поскольку вы показали, что с помощью простых объявлений массивов ваш код работает.
complex *data = calloc(10, sizeof(complex));
Приведенный выше код выделяет 10 сложных структур , и указатель указывает на первую выделенную. Чтобы перебрать их, вы можете индексировать их по номерам (например, data[0].real = 4) или использовать арифметику указателей. У меня есть сильное чувство, что вам придется изменить способ итерации по указателю data_out внутри функции csvread.
7 ответов
В Вашем случае параллельные чтения по Вашему массиву будут ориентированы на многопотоковое исполнение.
Что касается Вашей эффективности алгоритмов, в зависимости от размера Вашего массива, если это поместится в кэш затем, можно видеть превосходное увеличение производительности, поскольку мультиядра эффективно "борются" за кэш в ЦП. Если они будут бороться для заполнения кэша той же информацией, то они совместно используют значение большего количества удачных обращений в кэш и лучшей производительности.
Предположение, что массив вписывается в кэш...
Если бы производительность.NET и параллелизм под угрозой, я рекомендовал бы попытаться писать этот определенный алгоритм в F#. Компилятор F# сгенерирует код.NET, который имеет лучшую производительность 2-6.
Нет никакой причины не, читает содержание массива, одновременно предполагающего, что это довольно, никогда не будет изменяться. Нет никакой проблемы параллелизма следовательно никакой потребности скопировать.
Я сомневаюсь, что существует очень, можно сделать для создания его быстрее также.
Это не должно беспокоить Вас. Параллельное чтение не является проблемой. Любое количество потоков может считать ту же память одновременно.
Я не думаю, что существует проблема с параллельными чтениями. Это могло быть проблематично, если существуют параллельные записи, все же.
Неизменные данные по сути ориентированы на многопотоковое исполнение.
Потокобезопасность является только проблемой при обновлении данных. Если у Вас есть несколько параллельных потоков, обновляющих массив, необходимо будет перенести обновления (и чтения, если обновления не являются атомарными) в механизме синхронизации. Для структуры данных только для чтения параллелизм является надуманным вопросом.
Оператор присваивания не ориентирован на многопотоковое исполнение.
Это означает, читают ли Ваши потоки только массив - если массив был инициализирован в программе, запускаются, и не изменяется - затем Вы в безопасности.
Однако, если устройство записи существует, кто пишет новые значения, Вы уязвимы для состояния состязания.
Важный вопрос - это; читатель начинает читать целое число. Значение загружается из памяти в регистр. На данном этапе читатель выгружает. Устройство записи затем обновляет значение в памяти. Читатель затем загружает назад и действует на значение, которое он загрузил - который больше не корректен.
Это означает это вещи как if() не работайте надежно. Например,
if( int_array[5] == 10 )
{
}
Может инициировать когда значение в оперативной памяти int_array[5] больше не 10.
Я верю в C#, у Вас должен быть доступ к Interlocked*() вызовы функции, такой как InterlockedCompareAndSwap(). Они разрешат Вам легко достигать потокобезопасности в этом случае.