Модель памяти Java (JSR-133) подразумевают, что ввод монитора сбрасывает кэш (кэши) данных ЦП?
Вот пример кода, показывающий, как сделать то, что я изложил в комментарии. Я не могу проверить это, потому что у меня не установлено provider или pathos, но это должно дать вам хорошее представление о том, что я предложил.
import importlib
from pathos.helpers import mp
from provider import Provider
def process_data(loc):
module = importlib.import_module(loc)
provider_obj = Provider(module)
provider_obj.data_processing_func()
if __name__ == '__main__':
# list of data providers ... length is arbitrary
operating_providers = ['dataprovider1', 'dataprovider2', 'dataprovider3']
# create list of provider locations for each operating provider
provider_loc_list = []
for name in operating_providers:
loc = 'providers.%s' % name
provider_loc_list.append(loc)
processes = []
for loc in provider_loc_list:
process = mp.Process(target=process_data, args=(loc,))
process.daemon = True
process.start()
processes.append(process)
for process in processes:
process.join()
2 ответа
кеши, к которым имеет доступ JVM, на самом деле являются просто регистрами процессора. поскольку их не так много, очистка их при выходе из монитора не имеет большого значения.
РЕДАКТИРОВАТЬ: (в общем) кеши памяти не находятся под контролем JVM, JVM не может выбрать чтение / запись / очистка этих кешей, поэтому забудьте о них в этом обсуждении
представьте, что каждый процессор имеет 1 000 000 регистров. JVM с радостью использует их для сумасшедших быстрых вычислений - пока не столкнется с входом / выходом монитора и не сбросит 1 000 000 регистров на следующий уровень кэша.
если мы живем в этом мире, либо Java должна быть достаточно умной, чтобы анализировать, какие объекты не являются общими (большинство объектов не являются), либо она должна попросить программистов сделать это.
Модель памяти Java - это упрощенная модель программирования, которая позволяет средним программистам создавать хорошо многопоточные алгоритмы. под «упрощенным» я подразумеваю, что во всем мире может быть 12 человек, которые действительно прочитали главу 17 JLS и действительно поняли ее.
абсолютная необходимость синхронизации, даже если согласованность кеша гарантирована в аппаратное обеспечение
Да, но тогда вам нужно аргументировать только модель памяти Java, а не конкретную аппаратную архитектуру, на которой работает ваша программа. Кроме того, дело не только в оборудовании, компилятор и сами JIT могут изменить порядок инструкций, вызывая проблемы с видимостью. Конструкции синхронизации в Java последовательно обращаются к видимости и атомарности на всех возможных уровнях преобразования кода (например, компилятор / JIT / CPU / cache).
и, с другой стороны, плохая производительность на несогласованных архитектурах (полная очистка кеша)
Возможно, я неправильно понял s / t, но с несогласованными архитектурами вам все равно придется синхронизировать критические разделы. В противном случае вы столкнетесь со всевозможными условиями гонки из-за переупорядочения. Я не понимаю, почему модель памяти Java ухудшает ситуацию.
не должно быть более строгим (требуется информация, что охраняется monitor)
Я не думаю, что можно вообще приказать процессору очистить какую-либо конкретную часть кеша.Лучшее, что может сделать компилятор, - это создать заборы памяти и позволить процессору решать, какие части кеша нужно очистить - я полагаю, это все еще более крупнозернистый, чем то, что вы ищете. Даже если возможно более детальное управление, я думаю, что это сделает параллельное программирование еще более трудным (это уже достаточно сложно).
AFAIK, Java 5 MM (как и .NET CLR MM) более «строгий», чем модели памяти обычных архитектур, таких как x86 и IA64. Следовательно, это относительно упрощает рассуждение об этом. Тем не менее, он, очевидно, не должен предлагать s / t ближе к последовательной согласованности, потому что это значительно снизит производительность, поскольку может быть применено меньше оптимизаций компилятора / JIT / CPU / кеша.