Доброго времени суток.
Есть ли принципиальная возможность на х86 или AMD64 машинах разрыва операции massive[id]=val обрабочиком сигнала между вычислением адреса, куда положить val, и собственно самим помещением val по вычисленному адресу?
Спасибо.
Зависит от компилятора, но на ассемблере это можно сделать одной процессорной инструкцией.
>Зависит от компилятора, но на ассемблере это можно сделать одной процессорной инструкцией.
>Большое спасибо.
>Зависит от компилятора, но на ассемблере это можно сделать одной процессорной инструкцией.Не всегда. Зависит от сложности элемента массива.
pthread_mutex специально для таких ситуаций.
>Зависит от компилятора, но на ассемблере это можно сделать одной процессорной инструкцией.... с префиксом lock.
Только мне кажется что топикстартер хочет сделать что-то плохое. Я бы на его месте не стал полагаться на атомарность такой операции.
Спасибо за ответы. Не могли бы вы пояснить, что значит «сложность массива»? Сделать эту процедуру безопасной никаких проблем нет, но меня ужасает количество установок/снятий блокировок в коде. В обработчике сигналов временами требуется перевыделять память под глобальные массивы, с которым работает остальная часть кода. Идея была такова, что если использовать адрес указателя на динамический массив и индекс элемента массива, то всех блокировок можно и не делать, массив всегда будет правильно вычисляться по формуле а-ля (*address_of_pointer_to_global_dynamic_massive)[id]=val, несмотря на то, что сам указатель меняет свое значение при появлении сигнала. Пробные пуски показали, что все ОК, теперь вот пытаюсь узнать, может ли вообще такая конструкция сбоить.
>Спасибо за ответы. Не могли бы вы пояснить, что значит «сложность массива»?Я думал ты индекс меняешь в сигнале. Если элементы массива не примитивные, то смещение вычисляется сложно, и не всегда одной командой.
>В обработчике сигналов временами требуется перевыделять память
>под глобальные массивы, с которым работает остальная часть кода.Вот это кошмар. Не надо выделять память в обработчике сигнала, если не хочешь проблем.
Ни brk ни mmap не входят в списов функций разрешёных обработчику сигнала.
>массив всегда
>будет правильно вычисляться по формуле а-ля (*address_of_pointer_to_global_dynamic_massive)[id]=val, несмотря на то, что
>сам указатель меняет свое значение при появлении сигнала.Менять указатель в обработчике сигнала можно без блокировок.
>Пробные пуски показали,
>что все ОК, теперь вот пытаюсь узнать, может ли вообще такая
>конструкция сбоить.Может.
>>Спасибо за ответы. Не могли бы вы пояснить, что значит «сложность массива»?
>
>Я думал ты индекс меняешь в сигнале. Если элементы массива не примитивные,
>то смещение вычисляется сложно, и не всегда одной командой.опять же непонятно, что такое "примитивные элементы массива". Если размер елемента масива статичен и известен, то имеет ли какое-то значение что он из себя представляет?
>[оверквотинг удален]
>>будет правильно вычисляться по формуле а-ля (*address_of_pointer_to_global_dynamic_massive)[id]=val, несмотря на то, что
>>сам указатель меняет свое значение при появлении сигнала.
>
>Менять указатель в обработчике сигнала можно без блокировок.
>
>>Пробные пуски показали,
>>что все ОК, теперь вот пытаюсь узнать, может ли вообще такая
>>конструкция сбоить.
>
>Может.н-да... неутешительно, пошел медитировать над извращением логики программы.
>опять же непонятно, что такое "примитивные элементы массива". Если размер елемента масива статичен и известен, то имеет ли какое-то значение что он из
>себя представляет?Размер имеет значение. Смещение на лету считается для размеров в 1,2,4,8 байт. Для других размеров - необходимо считать смещение отдельно, то есть получается больше 1 операции.
>>опять же непонятно, что такое "примитивные элементы массива". Если размер елемента масива статичен и известен, то имеет ли какое-то значение что он из
>>себя представляет?
>
>Размер имеет значение. Смещение на лету считается для размеров в 1,2,4,8 байт.
>Для других размеров - необходимо считать смещение отдельно, то есть получается
>больше 1 операции.Не знал. Спасибо за разъяснения.
>В обработчике сигналов временами требуется перевыделять память
>под глобальные массивыНельзя так делать ни в коем случае.
>Доброго времени суток.
>Есть ли принципиальная возможность на х86 или AMD64 машинах разрыва операции massive[id]=val
>обрабочиком сигнала между вычислением адреса, куда положить val, и собственно самим
>помещением val по вычисленному адресу?
>Спасибо.а если подумать над тем что operator[]() вполне перегружаем, ы?
>>Доброго времени суток.
>>Есть ли принципиальная возможность на х86 или AMD64 машинах разрыва операции massive[id]=val
>>обрабочиком сигнала между вычислением адреса, куда положить val, и собственно самим
>>помещением val по вычисленному адресу?
>>Спасибо.
>
>а если подумать над тем что operator[]() вполне перегружаем, ы?Спасибо, vic. Не могли бы вы пояснить свою мысль, я не понимаю какое отношение перегружаемость оператора имеет к вопросу.
>>>Доброго времени суток.
>>>Есть ли принципиальная возможность на х86 или AMD64 машинах разрыва операции massive[id]=val
>>>обрабочиком сигнала между вычислением адреса, куда положить val, и собственно самим
>>>помещением val по вычисленному адресу?
>>>Спасибо.
>>
>>а если подумать над тем что operator[]() вполне перегружаем, ы?
>
>Спасибо, vic. Не могли бы вы пояснить свою мысль, я не понимаю
>какое отношение перегружаемость оператора имеет к вопросу.прямое, т.к. атомарности нифига не будет если используется не просто массив интов каких-нить, а что типа std::vector. Да и в случае массивов интов тоже гарантии нет. В методе оператора может быть и вывод на консоль засунут. А поручится за то что другой программист получивший ваш код в наследство не заменит ваш обычный массив на нечто более сложное с таким вот оператором, нельзя. Отсюда вывод - для атомарности всегда использовать locks/mutex предусмотренные стандартом.
Спасибо, коллеги, за ваши ответы. Похоже, единственное решение, увы, в извращении логики программы в сторону асинхронности выявления потребности и фактического выделения памяти. Не так красиво, не так эффективно, но никаких alloc-ов в обработчиках сигнала.