Ориентированные на многопотоковое исполнение атомарные операции в gcc
Это работает:
import matplotlib.pyplot as plt
fig, ax1 = plt.subplots(1,1)
x1 = [0,1,2,3]
squad = ['Fultz','Embiid','Dario','Simmons']
ax1.set_xticks(x1)
ax1.set_xticklabels(squad, minor=False, rotation=45)
5 ответов
Вы могли проверить gcc документацию. Для текущей gcc версии (4.3.2) это была бы глава 5.47 Встроенные функции для атомарного доступа к памяти - для других gcc версий, проверьте свои документы. Это должно быть в главе 5-Расширения Семейства языков C.
Кстати, компилятор C не делает абсолютно никакой гарантии относительно простых операций хранилища, являющихся атомарным. Вы не можете полагаться на то предположение. Для кода операции машины, который будет выполняться атомарно, этому нужен префикс БЛОКИРОВКИ.
На x86 и большей части другой архитектуры, выровненные 4 побайтовых чтения и записи являются всегда атомарными. Оптимизатор может пропустить/переупорядочить чтения и записи в единственном потоке, все же.
то, Что Вы хотите сделать, сообщают компилятору, что другие потоки, возможно, коснулись этой ячейки памяти. (Побочный эффект pthread_mutex_lock говорит компилятору, что другие потоки, возможно, коснулись любой части памяти.) Можно видеть volatile рекомендуемый, но это не в спецификации C и GCC не интерпретирует volatile тот путь.
asm("" : "=m" (variable));
frame->variable = variable;
GCC-определенный механизм, чтобы сказать, что" variable был записан в, перезагрузите его".
AFAIK, Вы не можете снабдить префиксом инструкции MOV БЛОКИРОВКУ; это позволяется только для операций RMW. Но если он делает , используют простое хранилище, ему, возможно, также понадобился бы барьер памяти, который неявен со взаимным исключением, а также с инструкциями, которые позволяют БЛОКИРОВКУ.
Как я вижу, вы используете платформу gnu для разработки, поэтому можно с уверенностью сказать, что glic предоставляет тип int данных в диапазоне атомных возможностей, sig_atomic_t' . Таким образом, этот подход может гарантировать выполнение атомарных операций на уровнях кернела, а не gcc.
До определенного момента атомарные операции в C предоставлялись прямо из исходных кодов ядра через заголовок atomic.h.
Однако использование заголовков ядра непосредственно в коде пользовательского пространства - очень плохая практика, поэтому файл заголовка atomic.h был удален некоторое время назад. Вместо этого мы можем теперь использовать «атомарные встроенные модули GCC», которые являются гораздо лучшим и более надежным подходом.
Есть очень хорошее объяснение, предоставленное Тюдором Голубенко в его блоге .Он даже обеспечивает замену исходного файла atomic.h на случай, если у вас есть какой-то код, который в этом нуждается.
К сожалению, я новичок в stackoverflow, поэтому могу использовать только одну ссылку в своих комментариях, так что проверьте сообщение Тюдора и узнайте.