Собираю материал по Memory Consistency Models of IMDGs.
Помогите кто чем богат:)
В корпоративном блоге Алексей Рогозин начал писать серию статей "Data Grid Pattern-s". Я зацепился за Data Grid Pattern - Network shared memory.
Как известно всякая Shared Memory должна обладать какой-то Memory Consistency Model. Но по бедноте материала на эту тему даже от "монстров" рынка: Oracle Coherence, IBM WebSphere eXtreme Scale стало понятно, что это "больное место" IMDG (да собственно и большинства NoSQL-решений).
Показаны сообщения с ярлыком Memory Model. Показать все сообщения
Показаны сообщения с ярлыком Memory Model. Показать все сообщения
среда, 16 февраля 2011 г.
суббота, 24 июля 2010 г.
What Do High-Level Memory Models Mean for Transactions?
What Do High-Level Memory Models Mean for Transactions?
Abstract
Many people have proposed adding transactions, or atomic blocks, to type-safe high-level programming languages. However, researchers have not considered the semantics of transactions with respect to a memory model weaker than sequential consistency. The details of such semantics are more subtle than many people realize, and the interaction between compiler transformations and transactions could produce behaviors that many people find surprising. A language’s memory model, which determines these interactions, must clearly indicate which behaviors are legal, and which are not. These design decisions affect both the idioms that are useful for designing concurrent software and the compiler transformations that are legal within the language.
Cases where semantics are more subtle than people expect include the actual meaning of both strong and weak atomicity; correct idioms for thread safe lazy initialization; compiler transformations of transactions that touch only thread local memory; and whether there is a well-defined notion for transactions that corresponds to the notion of correct and incorrect use of synchronization in Java. Open questions for a high-level memory-model that includes transactions involve both issues of isolation and ordering.
Abstract
Many people have proposed adding transactions, or atomic blocks, to type-safe high-level programming languages. However, researchers have not considered the semantics of transactions with respect to a memory model weaker than sequential consistency. The details of such semantics are more subtle than many people realize, and the interaction between compiler transformations and transactions could produce behaviors that many people find surprising. A language’s memory model, which determines these interactions, must clearly indicate which behaviors are legal, and which are not. These design decisions affect both the idioms that are useful for designing concurrent software and the compiler transformations that are legal within the language.
Cases where semantics are more subtle than people expect include the actual meaning of both strong and weak atomicity; correct idioms for thread safe lazy initialization; compiler transformations of transactions that touch only thread local memory; and whether there is a well-defined notion for transactions that corresponds to the notion of correct and incorrect use of synchronization in Java. Open questions for a high-level memory-model that includes transactions involve both issues of isolation and ordering.
пятница, 25 сентября 2009 г.
RSDN.ru: Что такое модель памяти? И с чем её едят?
Тут пост с rsdn.ru "Что такое модель памяти? И с чем её едят?" Дмитрий Вьюков кратко намечает что такое Memory Model для ПРОЦЕССОРА. Сам текст краток, но вот ссылки!
"Более детальную информацию по вопросу можно найти в документации по процессорам.
Например
для архитектур IA-32 и Intel-64 это "Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1":
http://www.intel.com/design/processor/manuals/253668.pdf
(CHAPTER 7 MULTIPLE-PROCESSOR MANAGEMENT)
Для Itanium это "Intel® Itanium® Architecture Software Developer’s Manual Volume 2: System Architecture":
http://download.intel.com/design/Itanium/manuals/24531805.pdf
(MP Coherence and Synchronization)
Для SPARC это "The SPARC Architecture Manual":
www.sparc.org/standards/SPARCV9.pdf
(8 Memory Models)
Так же хорошее введение в упорядочивание инструкций современными процессорами "Memory Ordering in Modern Microprocessors, Part I & II" (by Paul E. McKenney):
http://www.linuxjournal.com/article/8211
http://www.linuxjournal.com/article/8212"
"Более детальную информацию по вопросу можно найти в документации по процессорам.
Например
для архитектур IA-32 и Intel-64 это "Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1":
http://www.intel.com/design/processor/manuals/253668.pdf
(CHAPTER 7 MULTIPLE-PROCESSOR MANAGEMENT)
Для Itanium это "Intel® Itanium® Architecture Software Developer’s Manual Volume 2: System Architecture":
http://download.intel.com/design/Itanium/manuals/24531805.pdf
(MP Coherence and Synchronization)
Для SPARC это "The SPARC Architecture Manual":
www.sparc.org/standards/SPARCV9.pdf
(8 Memory Models)
Так же хорошее введение в упорядочивание инструкций современными процессорами "Memory Ordering in Modern Microprocessors, Part I & II" (by Paul E. McKenney):
http://www.linuxjournal.com/article/8211
http://www.linuxjournal.com/article/8212"
Подписаться на:
Сообщения (Atom)