Предложения

Очень красивая задачка, в неё надо добавить пункт в условие: 1. Разберитесь что делает программа.

Если преобразовать код аля компилятор, то без volatile будет примерно так:

public static class MakeProposal extends Thread {
    @Override
    public void run() {
        int proposal = Solution.proposal; //помещаем в кэш
        int thisProposal = proposal;

        while (proposal < 10) {
            System.out.println("Сделано предложение №" + (thisProposal + 1));
            proposal = ++thisProposal;
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        Solution.proposal = proposal; //возвращаем из кэша в медленную память
    }
}

MakeProposal инкрементирует переменную proposal до 10 и возвращает ее в медленную память. AcceptProposal:

public static class AcceptProposal extends Thread {
    @Override
    public void run() {
        int proposal = Solution.proposal; //помещаем в кэш 0, или,
       //если нить MakeProposal успела сделать несколько тактов, то больше
        int thisProposal = proposal;

        while (thisProposal < 10) {
            if (thisProposal != proposal) {
                System.out.println("Принято предложение №" + proposal);
                thisProposal = proposal;
            }
        }
        //сюда программа не дойдет
        Solution.proposal = proposal; //возвращаем из кэша в медленную память
    }
}

Тут наблюдаем бесконечный цикл, т. к. proposal и thisProposal всегда равны друг другу

Интересное наблюдение. В том виде, в каком задача подана сначала, IDE сразу же ставит предупреждение на строчку

if (thisProposal != proposal) {

"Условие всегда неверно" Чтобы убедиться в этом поставил

System.out.println(proposal);

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

System.out.println(proposal);

буквально на строку выше, перед проверкой условия. И о чудо. IDE убрала свое предупреждения. И программа отработала как надо (10 сделано 10 принято по порядку). Сначала я подумал, что из-за того что мы пользуемся переменной proposal в этом месте то jvm перестает хотеть делать ее локальную версию и работает с общей памятью, но потом снова ради интереса я изменил сроку на просто

System.out.print("");

и снова же, все отлично работает. То есть строка, которая по моим скудным знаниям вообще никак не должна влиять на программу, заставляет jvm изменить способ работы с переменной - способом аналогичным добавлением volatile. И что интересно IDE это видит и убирает предупреждение.

Мои предположения, в какой момент переменная proposal попадает в кэш. 1. Первый проход. Переменная proposal = 0 1.1. Запускается нить Accept, не происходит ничего, переменная не меняется. В методе run нити Accept сохраняется локальная переменная thisProposal = 0; 1.2. Запускается нить Make, выводится на экран "Сделано предложение №1 [т.к. 0 (текущее значение переменной proposal) + 1]". Значение переменной proposal инкрементируется. Нить засыпает. 2. Второй проход. Proposal = 1. 2.1. Пока нить Make спит, нить Accept успевает запуститься и выдать "Принято предложение №1" т.к. текущее значение переменной proposal уже 1, и по условию сравнения локальной переменной метода thisProposal с proposal, мы выдаём на экран вышеупомянутую фразу. Значение локальной переменной thisProposal становится = 1. 2.2. Нить Make просыпается, начинает работать с переменной proposal, инкрементирует её, переменная proposal (уже = 2) помещается в кэш (наверное по критерию кол-во обращений к переменной за некий короткий промежуток времени). "Медленная" память продолжает содержать значение proposal = 1. Нить Make засыпает. 2.3. Нить Accept, работая со значением proposal = 1, сравнивая её со значением локальной переменной своего метода thisProposal = 1, делает ничего. 2.4. Нить Make отрабатывает все значения proposal до 10. 2.5. Нить Accept продолжает молотить вхолостую, поэтому программа не завершается. Так?

Всего эту задачу решили 27311 учеников.

интересно, а кто-нибудь сделал synchronized proposal, до volatile такой же результат?

Здесь еще немаловажную роль играет слип в первом методе. Думаю если его убрать равномерности не получится даже с волатайле. Со слипом 1й метод играет как бы в поддавки со вторым - позволяет второму гарантированно себя догнать.

Хочется сказать : Люди, спасибо, что Вы есть! С Вами учиться гораздо интереснее (чем с Амиго)))

а теперь вопрос, как это сделать с помощью synchronized?

Убрал if в AcceptProposal, "синхронизовал" его через Thread.sleep() с MakeProposal, сначала предложение делается, потом принимается через равные промежутки времени. Решение ужасное, но рабочее)) Лишь на этапе валидации с комментарием про volatile понял, как она должна работать..