Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет mumuntu ([info]mumuntu)
@ 2011-07-20 04:36:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Я тут был на собеседовании (регулярно хожу, чаще, чем к врачу, это не значит, что я хочу работу сменить), и меня один коллега-джавадевелопер попросил решить известную задачу про две таблицы со связью между ними и все значения из первой таблицы, которые не имеют связи во второй таблице.
Когда я ему ответил, что надо сделать LEFT JOIN с WHERE <fk второй таблицы> IS NULL, он мне заявил, что это неоптимально, и предложил вариант с NOT EXISTS.

Дорогие коллеги-джавадевелоперы!
Если в вашей голове запрос с NOT EXISTS в плане выглядит оптимальнее, чем запрос с LEFT JOIN, крайне рекомендую синхронизировать ваше внутреннее представление с реальным планом запроса базы.
А еще лучше - не беритесь рассуждать о том, в чем не разбираетесь.
Что интересно, коллега мне еще сказал, что в случае с NOT EXISTS не нужен подзапрос (?). Я не знаю, как это трактовать, совсем вы офигели в своей джаве.

Upd.: в комментариях и в связанной записи коллеги [info]plumqqz@lj произошло интересное обсуждение, по результатам которого я пошел и нашел блогозапись коллеги Quassnoi, в которой изложена вся информация по теме LEFT JOIN vs NOT EXISTS применительно к MySQL.


(Читать комментарии) - (Добавить комментарий)


[info]alexshubert@lj
2011-07-20 03:29 (ссылка)
Парень, заваливший меня на собеседовании в mail.ru, сообщил, что CAS-операции в sun.misc.unsafe "ломаются" при превышения некоторого количества асинхронных операций. И что проблема даже не в них, а в самой архитектуре процессора, то есть, ломается сама архитектура многоядерных процессоров. Код или пример привести отказался.

(Ответить) (Ветвь дискуссии)


[info]lionet@lj
2011-07-20 05:00 (ссылка)
Может он про это: http://en.wikipedia.org/wiki/Memory_ordering

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexshubert@lj
2011-07-20 06:02 (ссылка)
Либо я не понимаю сути, либо CAS операции гарантируют выполнение проверил-установил. А в статье речь о том, что что могут быть перемешаны операции, в угоду оптимального использования кэша, если они не затрагивают барьеры. СAS, конечно, не барьер, но если бы он "ломался" под нагрузкой, то, по-моему, это бы означало конец мультипоточной разработки в целом. я ошибаюсь?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]lionet@lj
2011-07-20 07:15 (ссылка)
Да, просто CAS работает на x86. На других платформах должен быть memory barrier, потому что cas гарантирует ордеринг обращений к одному слову памяти. Но что может происходить в соседних кэш-лайнах — не гарантируется.

Пример.

У тебя есть какая-то структура, которая висит за поинтером, который защищён CAS. Локфри. Ты идёшь туда по поинтеру, читаешь структуру, делаешь её копию, изменяешь какие нужно тебе поля. Затем поинтер меняешь через CAS, замещая старую структуру новой.

Казалось бы, всё ок — у тебя произошла атомарная операция записи, и все кто пришёл после неё видят новую структуру.

Но на самом деле на некоторых процессорах (Alpha) может произойти такая шняга: другие ядра увидят операцию CAS и смену поинтеров раньше, чем заполнение новой структуры. В итоге они пойдут, прочитают поинтер (новый), но будут работать со структурой, в которой часть полей не до конца заполнены.

И естественно, на однопроцессоре это будет создавать видимость работоспособности, и при небольшой (или неоптимальной) загрузке во многопроцессорной конфигурации будет создавать видимость работоспособности. Но на самом деле одного CAS в общем случае недостаточно.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexshubert@lj
2011-07-20 07:22 (ссылка)
Последний абзац применим к x86?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]lionet@lj
2011-07-20 07:49 (ссылка)
Неа.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexshubert@lj
2011-07-20 07:51 (ссылка)
Спасибо за пояснения.

(Ответить) (Уровень выше)


[info]ext_563095@lj
2011-07-20 08:52 (ссылка)
CAS в смысле memory ordering эквивалентен fence instructions, тут вы правы. Если "ломается архитектура многоядерных процессоров", это значит что-то не так в c memory coherence protocol (MESI (http://en.wikipedia.org/wiki/MESI_protocol)). Впервый раз про это слышу - жалко что этот парень не выдал каких-нибудь ссылок на почитать...

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ext_563095@lj
2011-07-20 09:00 (ссылка)
Вот еще ссылочка, в том числе затрагивающая тему CAS на MPS: http://blogs.oracle.com/dave/entry/biased_locking_in_hotspot
Под CAS (на x86) они имеют ввиду LOCK:CMPXCHG.

(Ответить) (Уровень выше)


(Читать комментарии) -