Java: соглашения об именах для безопасности потоков? - PullRequest
1 голос
/ 15 декабря 2010

Представьте, что у меня есть этот класс:

class Notifier {
    public Listener listener;

    public void notify() {
        if (listener != null) {
            listener.stuffHappens();
        }
    }
}

Этот код неверен в случае, если listener можно изменить из другого потока. Давайте исправим это:

class Notifier {
    public volatile Listener listener;

    public void notify() {
        Listener l = listener;
        if (l != null) {
            l.stuffHappens();
        }
    }
}

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

Мой первый импульс - назвать переменную volatileListener --- при условии, что она частная и, конечно, есть setListener(), но я представляю себе реакцию коленного рефлекса "венгерская запись - это зло" от многих людей.

Итак, существуют ли установленные практики / соглашения? Или, может быть, есть некоторые закономерности, позволяющие систематически избегать подобных ситуаций. Что вы делаете, когда пишете многопоточный код?

Ответы [ 3 ]

4 голосов
/ 15 декабря 2010

Что вы делаете, когда пишете многопоточный код?

Отделите код, который заботится о потоке, от кода, который этого не делает.

Хорошим началом является наличие класса, отвечающего за уведомления, но ваш комментарий об "изменении прослушивателя из другого потока" вызывает беспокойство - и сделать вашу переменную listener общедоступной еще более тревожной. Сделайте его закрытым и добавьте методы к Notifier для контроля изменений.

И не добавляйте в Notifier код, который делает что-либо кроме уведомления слушателей .

1 голос
/ 15 декабря 2010

Брайан Гетц предложил в своей книге «Параллелизм Java на практике» использовать аннотации для пометки полей и классов как потоковых или нет.

http://www.javaconcurrencyinpractice.com/annotations/doc/net/jcip/annotations/package-summary.html

(Нервесс Анон прав, сохранить отдельный поток и не сохранить код.)

1 голос
/ 15 декабря 2010

Это не соглашение об именах, но в Java Concurrency на практике авторы предлагают использовать аннотации для описания политик безопасности потоков.

Я очень рекомендую эту книгу всем, кто пишет многопоточный код на Java.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...