Написание синхронизированной оболочки безопасности потока для NavigableMap - PullRequest
Новая
       28

Написание синхронизированной оболочки безопасности потока для NavigableMap

2 голосов
/ 15 мая 2010

java.util.Collections в настоящее время предоставляют следующие служебные методы для создания оболочки synchronized для различных интерфейсов сбора:

Аналогично, он также имеет 6 unmodifiedXXX перегрузок.

Здесь явное упущение - это служебные методы для NavigableMap<K,V>. Это правда, что это extends SortedMap, но у SortedSet extends Set, Set extends Collection и Collections есть специальные служебные методы для SortedSet и Set. Предположительно, NavigableMap - полезная абстракция, иначе ее не было бы вообще, и все же для нее нет служебных методов.

Итак, вопросы:

  • Есть ли конкретная причина, по которой Collections не предоставляет служебные методы для NavigableMap?
  • Как бы вы написали свою собственную synchronized оболочку для NavigableMap?
    • Взглянув на исходный код для OpenJDK-версии Collections.java, можно предположить, что это просто «механический» процесс
      • Правда ли, что в общем случае вы можете добавить synchronized функцию обеспечения безопасности нитей, как эта?
      • Если это такой механический процесс, можно ли его автоматизировать? (Eclipse-плагин и т. Д.)
      • Это повторение кода необходимо, или его можно было избежать с помощью другого шаблона проектирования ООП?

Ответы [ 4 ]

4 голосов
/ 16 мая 2010

Это был недосмотр. Исправление продолжается .

Джош пишет:

"Они определенно принадлежат там. Их отсутствие непреднамеренно.
Мы должны положить их как можно скорее. "

Я согласен, хотя никто из нас, инженеров, не смотрит вперед написание (и тестирование) всех этих ошеломляющих методов пересылки. Дата публикации: 2006-08-21 00: 50: 41.0

Хотя требуется время.

Обновление : что касается его ручной реализации, вы можете подумать о перехвате пакета java.util, поскольку вы хотите расширить static class SynchronizedSortedMap<K, V>, который объявлен закрытым пакетом. Иначе это будет много копировальной пасты кода. Вот начало игры: 

package java.util;

import java.util.Collections.SynchronizedSortedMap;

public class NewCollections {

    public static <K, V> NavigableMap<K, V> synchronizedNavigableMap(NavigableMap<K, V> m) {
        return new SynchronizedNavigableMap<K, V>(m);
    }

    static class SynchronizedNavigableMap<K, V> extends SynchronizedSortedMap<K, V> implements NavigableMap<K, V> {
        private final NavigableMap<K, V> sm;

        SynchronizedNavigableMap(NavigableMap<K, V> m) {
            super(m);
            sm = m;
        }

        SynchronizedNavigableMap(NavigableMap<K, V> m, Object mutex) {
            super(m, mutex);
            sm = m;
        }

    }
}

Пусть среда IDE автоматически сгенерирует нереализованные методы NavigableMap и закодирует их так же, как SynchronizedSortedMap. Вот ОДИН пример: 

        @Override
        public K ceilingKey(K key) {
            synchronized (mutex) { return sm.ceilingKey(key); }
        }

Обратите внимание, что методы, которые возвращают, например, Set, вам также нужно обернуть его в SynchronizedSet. Опять же, посмотрите источники SynchronizedMap и SynchronizedSortedMap для понимания:)

Я не ожидаю, что это будет (может быть) механический процесс, поскольку он включает в себя множество факторов.

2 голосов
/ 15 мая 2010

Это правда, что в целом вы можете добавить синхронизированная функция безопасности потоков как это?

Я верю, что это правда. Определение безопасности потока (IMO),

Класс является поточно-ориентированным, если для всех его методов не может быть некорректного поведения (которое не может возникнуть при использовании из одного потока) при вызове из нескольких потоков без какой-либо внешней синхронизации.

Теперь приведенный ниже код гарантирует, что «Нечто» никогда не вызывается несколькими потоками, верно? Поэтому я полагаю, что никакое неблагоприятное поведение не может возникнуть из-за того, что оно вызывается несколькими потоками; Он никогда не вызывается из нескольких потоков!

Это, вероятно, также идея EJB. EJB без сохранения состояния никогда не вызываются более чем одним потоком (обеспечивается контейнером). Вот почему в спецификации EJB может быть сказано: «Вам не нужно беспокоиться о безопасности потоков». 

public class MakeSomethingThreadSafe implements Something {
    private final Object lock = new Object();
    private final Something subject;

    public MakeSomethingThreadSafe(Something subject){
        this.subject = subject;
    }

    public void someMethod(){
        synchronized(lock){
            subject.someMethod();
        }
    }
}

Или я что-то упустил?

Чтобы завершить публикацию:

Есть ли конкретная причина, почему Коллекции не предоставляют полезности методы для NavigableMap?

Я согласен со Стивеном.

Как бы ты написал свой синхронизированная оболочка для NavigableMap?

Как мой пример кода ..

Правда ли, что вообще можно добавить синхронизированная функция безопасности потоков как это? Если это такой механический процесс, это может быть автоматизировано? (Затмение подключаемый модуль и т. д.)

Да, я думаю, это можно легко автоматизировать.

  1. Реализация интерфейса
  2. Сделать 2 поля; Один для мьютекса, один для субъекта.
  3. Создание конструктора для ввода темы.
  4. Сделайте каждый метод синхронизированным и делегируйте субъекту.

Это повторение кода необходимо, или можно было бы избежать другой шаблон дизайна ООП?

Как для Set, Map и т. Д.? Для меня не представляется возможным решить это "нормальным" способом ..

1 голос
/ 10 июля 2014

К вашему сведению, Java 8 теперь имеет:

private NavigableMap<Date,T> map = Collections.synchronizedNavigableMap(...);

См. Документ Java8 на навигационной карте

1 голос
/ 15 мая 2010

Есть ли конкретная причина, по которой в Collections не предусмотрены служебные методы для NavigableMap?

Я не могу придумать конкретную причину. Это либо

  • недосмотр,
  • случай "вряд ли кто-нибудь будет его использовать", или
  • возможно, есть какая-то техническая сложность, которая не очевидна.

Но в любом случае причина на самом деле не имеет значения. Утилиты нет, поэтому вы либо найдете стороннюю библиотеку, либо внедрите ее самостоятельно.

Правда ли, что в общем случае вы можете добавить синхронизированную функцию обеспечения безопасности потоков, как эта?

Вообще нет. Вы должны понимать семантику класса, который вы связываете, чтобы сделать поток безопасным, чтобы выяснить, достаточна ли оболочка.

Если это такой механический процесс, можно ли его автоматизировать? (Eclipse-плагин и т. Д.)

Нет ... см. Выше.

Это повторение кода необходимо, или его можно было избежать с помощью другого шаблона проектирования ООП?

Я не думаю, что этого можно избежать. Для такого рода вещей потребуется лингвистическая поддержка метапрограммирования в целом или для конкретного случая написания классов-оболочек. Шаблоны проектирования не делают такого рода вещи для вас.

...