Здравствуйте, Cyberax, Вы писали:
GI>>27. Что такое "test-and-test-end-set"? C>"Test And Test-And-Set"?
C>Кстати, а где классический вопрос про double check singleton?
"Test And Test-And-Set" по сути и есть double check idiom.
Здравствуйте, -VladK-, Вы писали:
GI>>>27. Что такое "test-and-test-end-set"? C>>"Test And Test-And-Set"? C>>Кстати, а где классический вопрос про double check singleton? VK>"Test And Test-And-Set" по сути и есть double check idiom.
Весь вопрос в барьерах
Здравствуйте, ivanU, Вы писали:
C>>Из той же оперы — не надо наследовать свои классы от Thread(), особенно если в них есть метод setName() U>А как лучше делать и почему?
Реализовывать интерфейс Runnable и передавать параметром в конструктор Thread.
C>>>Из той же оперы — не надо наследовать свои классы от Thread(), особенно если в них есть метод setName() U>>А как лучше делать и почему? C>Реализовывать интерфейс Runnable и передавать параметром в конструктор Thread.
Извиняюсь за настырность, но чем такой вариант лучше?
До последнего времени использовал наследование от Thread, никаких подводных камней пока не попадалось.
Здравствуйте, ivanU, Вы писали:
C>>Реализовывать интерфейс Runnable и передавать параметром в конструктор Thread. U>Извиняюсь за настырность, но чем такой вариант лучше? U>До последнего времени использовал наследование от Thread, никаких подводных камней пока не попадалось.
Зачем наследоваться от полноценного класса, если ничего не собираешься использовать, кроме самописаного метода run? Меньше сущностей — больше порядка.
И уже было сказано, что ты можешь получить логическую ошибку (было про метод setName), если не проанализируешь поведение класса, от которого наследуешься.
Здравствуйте, ivanU, Вы писали:
C>>>>Из той же оперы — не надо наследовать свои классы от Thread(), особенно если в них есть метод setName() U>>>А как лучше делать и почему? C>>Реализовывать интерфейс Runnable и передавать параметром в конструктор Thread.
U>Извиняюсь за настырность, но чем такой вариант лучше? U>До последнего времени использовал наследование от Thread, никаких подводных камней пока не попадалось.
В теории ООП считается, что включение порождает меньшую связанность, чем наследование; что в свою очередь благоприятно сказывается на сложности системы.
Например, если ты реализовал какую-то задачу как Runnable, то потом ты можешь запустить её в отдельном потоке с помощью Thread, или запустить её в пуле потоков Fork/Join с помощью ForkJoinTask, или передать в какую-либо другую стороннюю или свою библиотеку для асинхронного или даже синхронного выполнения. Если же ты жёстко отнаследовал от Thread, то ничего такого ты сделать не сможешь (по крайней мере без создания объектов Thread).
Ну и плюс, уже упомянутые, нежелательные коллизии имён.
ANS>>System.out.println(Thread.isInterrupded());
ANS>>System.out.println(Thread.isInterrupded());
ANS>>/... vs. .../
ANS>>System.out.println(aThread.interrupded());
ANS>>System.out.println(aThread.interrupded());
ANS>>
ANS>>Будет ли различным результат обоих кусков, если aThread это текущая нить. C>Будут, так как isInterrupted() без параметров не очищает флаг interrupted, а interupted() — очищает. Повбывав бы.
Кстати, вечно путаю эту хрень. Согласен с "Повбывав бы" — всегда надо в документашку лезть.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
C>>>Реализовывать интерфейс Runnable и передавать параметром в конструктор Thread.
U>>Извиняюсь за настырность, но чем такой вариант лучше? U>>До последнего времени использовал наследование от Thread, никаких подводных камней пока не попадалось.
R>В теории ООП считается, что включение порождает меньшую связанность, чем наследование; что в свою очередь благоприятно сказывается на сложности системы. R>Например, если ты реализовал какую-то задачу как Runnable, то потом ты можешь запустить её в отдельном потоке с помощью Thread, или запустить её в пуле потоков Fork/Join с помощью ForkJoinTask, или передать в какую-либо другую стороннюю или свою библиотеку для асинхронного или даже синхронного выполнения. Если же ты жёстко отнаследовал от Thread, то ничего такого ты сделать не сможешь (по крайней мере без создания объектов Thread). R>Ну и плюс, уже упомянутые, нежелательные коллизии имён.
Стало понятнее, благодарю
А что имелось в виду под "по крайней мере без создания объектов Thread" — как без его создания
я могу запустить свою Runnable задачу (без фреймворков, core java)?
Здравствуйте, ivanU, Вы писали:
U>А что имелось в виду под "по крайней мере без создания объектов Thread" — как без его создания U>я могу запустить свою Runnable задачу (без фреймворков, core java)?
U>>А что имелось в виду под "по крайней мере без создания объектов Thread" — как без его создания U>>я могу запустить свою Runnable задачу (без фреймворков, core java)?
C>
C>yourRunnable.run()
C>
сорри, забыл написать в прошлом посту — в отдельном потоке конечно — я правильно
понимаю, что без создания объекта Thread это невозможно (core java)?
Здравствуйте, ivanU, Вы писали:
U>сорри, забыл написать в прошлом посту — в отдельном потоке конечно — я правильно U>понимаю, что без создания объекта Thread это невозможно (core java)?
Да.
Здравствуйте, ivanU, Вы писали:
U>А что имелось в виду под "по крайней мере без создания объектов Thread" — как без его создания U>я могу запустить свою Runnable задачу (без фреймворков, core java)?
Я имел в виду следующую ситуацию. Допустим класс задачи всё-таки отнаследован от Thread, а мы хотим запустить эту задачу как Fork/Join Task.
Решение конечно не очень хорошее, но теоретически можно создать объект нашего класса, и он тоже будет реализовывать Runnable (т.к. Thread реализует Runnable), и потом из него создать Fork/Join Task. Это решение с созданием объектов Thread, без создания же объектов Thread из нашего класса не получится создать Fork/Join Task (это я имел в виду под "по крайней мере без создания объектов Thread").
Я попробую в одном посте ответить на все замечания.
1) "написать короткие ответы на эти вопросы" — тут короткими ответами не отделаешься, выйдет десяток страниц.
2) "Интересно, а если я могу ответить (подробно, с примерами) где-то на 40 вопросов — это много?" — это только потенциальный работодатель может решить
3) "Test And Test-And-Set"? — да, так более корректно
4) "Тут точно CSP или всё-таки CPS?" — да, именно то хоаровское CSP==Communicating Sequential Processes являющееся скорее нотацией, а не реальным языком программирования. Немного провокационный. Знает ли интервьюируемый вообще про существование CSP, что знает, и если более-менее хорошо знает, то может ему в нем что-то особенно запомнилось/понравилось.
5) "Кстати, а где классический вопрос про double check singleton?" — скорее идиоматическим названием является double-checked locking [The "Double-Checked Locking is Broken" Declaration == http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html]. Если бы целью ставил всесторонние тесты — обязательно бы присутствовал, а так не хотелось вставлять уж слишком ожидаемый вопрос.
6) ""Test And Test-And-Set" по сути и есть double check idiom" — тут не могу согласиться. Скажем, у DCL в варианте из ссылки выше присутствует разбор полета конструктора в Java. какие-то параллели есть, но не тождество.
7) "Подскажете, что имеет смысл читать, кроме java concurrency in practice? Понятно, что можно насобирать по кусочкам в инете, но есть ли что-то системное?"
— Doug Lee. Concurrent Programming in Java. Design Principles and Patterns — Addison Wesley — 2nd edition
— The Art of Multiprocessor Programming (Maurice Herlihy, Nir Shavit)
— по алгоритмам: The little book of semaphores = http://www.greenteapress.com/semaphores/
— по структурам данных: "Concurrent Data Structures" = http://www.cs.tau.ac.il/~shanir/concurrent-data-structures.pdf
— по JMM возьмите отсюда — http://kharkovconcurrencygroup.blogspot.com/2009/09/jmm.html
— advanced JMM = очень полное и детальное описание модели памяти Java (Java Memory Model, JMM) с описанием целей, которые ставились при разработке, и компромиссных решений, которые приходилось принимать = http://unladen-swallow.googlecode.com/files/journal.pdf (thanks to Remark)
— это тусовка вообще всех товарищей из Java concurrency community = http://cs.oswego.edu/pipermail/concurrency-interest/
GI>6. Напишите минимальный copy-on-write ArrayList (всего четыре метода — void add(int indx, int item), int get(int indx), void remove(int indx), int size()).
желательно знать что такая реализация есть в JDK = http://java.sun.com/javase/6/docs/api/java/util/concurrent/CopyOnWriteArrayList.html
GI>9. Некоторые из следующих методов deprecated а некоторые и не были никогда реализованы. Какие? Thread.interrupt(), Thread.stop(), Thread.yield(), Thread.suspend(), Thread.resume(), Thread.join(), Thread.start(), Thread.run(), Thread.sleep().
Базовая статья = http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
GI>10. Что Вы знаете о асинхронных вызовов методов? Есть ли это в самом языке Java? Если есть, то как реализовано? Если нет, то как бы Вы реализовали?
Нет, рассказать как сделать на Future. Возможно интервьюируемый знает язык с реализацией.
GI>13. В классе String все поля финальные. Можно ли убрать ключевое слово финал? Ведь сеттеров все равно нет — следовательно поля нельзя переустановить.
Изменилась семантика ключевого слова final начиная с Java 5. Теперь просто убрать нельзя. Иначе при non safe publishing строка может вести себя как мутирующая (до Java 5 так могла себя вести и с final). = http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#finalWrong. "The original Java Memory Model allowed this behavior; several JVMs have exhibited this behavior. The new Java Memory Model makes this"
GI>16. Что из данных вызовов создает happend-before: Thread.sleep(), Thread.join(), Thread.yield(), Thread.start(), Thread.run(), Thread.isAlive(), Thread.getState()?
H-B: Thread.join(), Thread.start()
GI>21. Что такое "private mutex"? http://c2.com/cgi/wiki?PrivateMutex
GI>38. Что такое "condition waiting"? Примеры как добиться в Java.
Ожидается просто рассказ про wait()/notify()-notifyAll() + j.u.c.lock.Condition
GI>41. Что в SynchronousQueue уникально для BlockingQueue.
То что нет размера.
GI>42. Что такое "рандеву"? При помощи каких классов в Java его можно организовать?
наиболее стандартно:
Передача в одну сторону — SynchronousQueue
Обмен — Exchanger
GI>43. Что такое "false sharing". Может ли происходит в Java. Если есть, то приведите примеры и как бороться. Если нет, то как побороли разработчики JVM.
— может
— из спеки не следует что массивы и поля объекта расположены в непрерывной области памяти(нет адресной арифметики), но обычно так и есть.
— просто интересные мысли
-- зачастую память в потоке выделяется из thread local buffer — и это немного уменьшает ложное разделение. Плюс перемещающий GC (copy-, compact- , etc) может объекты принадлежащие одному потоку расположить рядом (но тут не знаю вышли ли такие разработки за пределы лабораторий).
GI>44. Thread.getState() возвращает экземпляр Thread.State. Какие возможны значения?
Собственно попытка подловить (в том числе) на понимании разницы между Thread.State.WAITING и Thread.State.BLOCKING.
GI>46. У ReentrantLock созданного с аргументом true все же один из методов захвата блоктровки — не fair. Какой? Как это обойти?
.tryLock(), "If you want to honor the fairness setting for this lock, then use tryLock(0, TimeUnit.SECONDS) which is almost equivalent (it also detects interruption)."
GI>47. Приведите наиболее существенное отличие между CountDownLatch и Barrier.
Ожидаемый ответ — CyclicBarrier(извинения за описку) — "многоразовый", а CountDownLatch — "одноразовый".
GI>48. Что Вы знаете о Erlang? Что в нем есть существенного связанного с многопоточностью такого, чего нет в Java?
Ожидаемое начало ответа — легковесные потоки. Но тут зависит насколько соискатель знает Erlang
Здравствуйте, Аноним, Вы писали:
А>Спасибо, теперь я знаю что ничего не знаю А>Подскажете, что имеет смысл читать, кроме java concurrency in practice? Понятно, что можно насобирать по кусочкам в инете, но есть ли что-то системное?
У меня в голове крутится, что книга Java. Concurrency in Practice является как бы следующим изданием, "переработанным и дополненным" к той, что Вы упоминаете. Это действительно так, или книги совершенно разные и читать надо обе?
