Memory Ordering in Modern Microprocessors

Memory Ordering in Modern Microprocessors (Part I, Part II).

"Linux provides a carefully chosen set of memory-barrier primitives, as follows:

• smp_mb(): “memory barrier” that orders both loads and stores. This means loads and stores preceding the memory barrier are committed to memory before any loads and stores following the memory barrier.
• smp_rmb(): “read memory barrier” that orders only loads.
• smp_wmb(): “write memory barrier” that orders only stores.
• smp_read_barrier_depends(): forces subsequent operations that depend on prior operations to be ordered. This primitive is a no-op on all platforms except Alpha."
  
  
  
  
  "All of Linux's locking primitives, including spinlocks, reader-writer locks, semaphores and read-copy updates (RCUs), include any needed barrier primitives."
  
  
  P.S. Тут, видимо, вариант той же самой статьи.
  P.P.S. Эти статьи можно использовать как введение к более сложному чтиву - "What Every Programmer Should Know About Memory" (114 pages).

Use cases for weakCAS

В java.util.concurrent.atomic.AtomicXXX есть волшебный метод weakCompareAndSet, который отличается от оригинального  compareAndSet двумя моментами:

1) может  spuriously fail "The weak version may be more efficient in the normal case, but differs in that any given invocation of weakCompareAndSetmethod may fail, even spuriously (that is, for no apparent reason)."

2) не устанавливает happend-before отношение "weakCompareAndSet atomically reads and conditionally writes a variable, is ordered with respect to other memory operations on that variable, but otherwise acts as an ordinary non-volatile memory operation."

---

Для такого поведения (второй пункт) найдено пока два Use Case:

A) счетчики

B) Michael-Scott queues (надо попробовать реализовать)

P.S. Как понимаю, j.u.c.ConcurrentLinkedQueue реализовано на основе Michael-Scott queue, но использует "strong" CAS.

Efficient data transfer through zero copy

Efficient data transfer through zero copy.

Суть: при копировании File -> Socket через transferTo удается избежать лишних копирований данных и переключений user mode <-> kernel mode. Остается два копирования, но они делаются не через CPU, а через DMA.

Вопрос: возможно ли достичь аналогичного эффекта при копировании Socket -> Socket? Пока ищу ответ. Скажем, если я использую ByteBuffer.allocateDirect(...).

Докладываю доклад

Добрый день,
в следующую Сб расскажу "Java: пишем SOCKS4/5 proxy server на 10.000 соединений."

Было бы интересно Ваше мнение: уклон в какую сторону доклада такого типа Вас бы наиболее привлек?
- отдать весь код сервера/реализации протокола;
- сравнение с другими языками/подходами: Erlang, Node.js, etc;
- предоставлен анализ источников (книги/статьи по теме/полезные блоги);
- ...

Серверная и Контейнерная части EJB серверов: OpenEJB

Вероотступник Geronimo: OpenEJB и реализация EJB в Apache Geronimo.
    "OpenEJB, фактически, состоит из двух частей: сервера и контейнера, и команда прилагает все усилия, чтобы не смешивать их. В спецификации EJB говорится о контейнере и сервере как о раздельных частях, но нигде не даётся определение этих частей. OpenEJB устанавливает соглашение "контейнер-сервер", и, в конце концов, серверная часть OpenEJB была включена в Geronimo без каких-либо серьёзных изменений, а контейнер был полностью переписан для проекта. "Мы не используем Jetty целиком и не полностью используем OpenEJB, который существовал до создания Geronimo," заметил Дэвид. "Одна из вещей, которой [члены сообщества Geronimo] могут гордиться, состоит в том, что мы не склеивали части в произвольном порядке и не представили всем эдакого Франкенштейна".
    Серверная сторона OpenEJB содержит распределённую часть уравнения. В любой распределённой системе должны присутствовать две вещи: способность находить компонент или сервис, которые вы хотите использовать, а также способ их вызова после того, как они найдены. Отыскание компонента или сервиса обычно происходит с использованием какого-либо реестра. В веб-сервисах это -- Universal Description, Discovery and Integration (UDDI). В CORBA это -- CosNaming. В EJB это -- Java Naming и Directory Interface (JNDI). В идеале, вы должны иметь возможность позаботиться о второй части -- о вызове компонентов (будь это веб-сервис, CORBA-процедура, или удалённый EJB) при помощи обычных программных средств. Другими словами, вы должны иметь возможность вызывать компонент, как если бы он был локальным объектом.
    Серверная часть среды управляет этим процессом вызова, проверяя, что вызов достигает удалённого объекта, и что ответ возвращается к клиенту. Сервер также управляет такими задачами, как "передача состояния безопасности транзакции между вызовами," сказал Дэвид."
---
Как-то я не думал так о Java EE серверах.

JMS 2.0: Support for Multi-tenancy

Java EE 7 будет серьезно сфокусирована на clouds/PaaS и, как следствие, на обеспечении multitenancy [Arun Gupta about Java EE 7].

Нашел документ, описывающий как multitenancy, возможно, будет введена в JMS 2.0 (JMS 2.0 - часть Java EE 7) - JMS 2.0: Support for Multi-tenancy.

A Note on Distributed Computing

A Note on Distributed Computing

Суть
Каждые 10 лет приходит новая волна моды на распределенные вычисления. 70-е - передача сообщений, 80-е - RPC, 90-е - распределенныные объекты (статья 94го года). Но основная проблема не в модели связывания computation + communication, а в принципиальных сложностях: latency, different model of memory access, concurrency, partial failure, lack of a central resource manager. Похоже, авторы - разработчики NFS.

Abstract

    We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure.
    We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible.
    We conclude by discussing what is required of both systems-level and application-level programmers and designers if one is to take distribution seriously.