Ладно, с кривотой volatile я разобрался. Причина: какой-то индус-студент, пришедший в Microsoft набраться опыта, решил не давать гарантии атомарности чтений/записей типам long/double, хотя это сделать эелментарно (хотя бы просто делеировать в Interlocked). Потом через какое-то время появились дженерики, за которыми могли стоять все те же long и double. Но вместо того, что бы снять это ограничение (а из-за этого legacy код бы совершенно не пострадал), другой индус-студен решил запретить volatile и для дженериков. Из-за этого мы имеем кривой и косой API. Проехали.

Следующая кривота. ThreadPool. Такого маразма я давно не видел:
1) Какой идиот решил сделать его общим на все приложение? Что он курил?
2) И зачем он смешал воедино обычныйе треды-воркеры и треды для completion ports?
3) И почему он не дал нам возможность нормально сконфигурировать его?

Теперь расскажите мне, господа дотнетовцы, как вы будете решать следующие задачи с помощью этого уродца:
1) У вас в приложении генерируются задачи, которые надо выполнять последовательно одну за другой по мере их появления (примерно как это сделано с UI). Как вы этого будете делать? В Java я могу создать отдельный тред пул с ровно одним потоком, и класть в него задачи. Одна строчка кода. В .Net мне надо изобретать свой велосипед с while-циклами, блокирующими колелкциями и прочим дерьмом, которое характерно для тред-пулов.
2) Вы делаете нечто вроде map-reduce фреймворка. Пользователь дает вам задачи, вы их кладете в тред-пул. Каждая задача может сгенерировать другие задачи, которые пойдут в этот же тред-пул, и т.д.. Но кроме пользовательских задач, у вашего приложения еще есть свои системные задачи, которые должны быть гарантированно исполнены и исполнены быстро. Вопрос на засыпку - сможете ли вы использовать ThreadPool в этом случае? Хрен вам, господа! Ведь если юзерские задачи засрут вам пул, то время выполнения вашей системной задачи будет расти пропорционально размеру очереди пользовательских задач. И опять - пищем свои велосипеды. А в Java надо просто создать два разных пула - один для пользователей, один для себя. И все.

Очередному индусу в программистском угаре пришла в голову идея сделать ThreadPool статическим, и все - вся идея тут же становится ограниченной и корявой. А надо то было просто конструкторик ThreadPool сделать публичным, что бы разработчики могли создавать свои пулы. Пару строчек кода поленились добавить.

Где-то в степивот про это поподробней расскажите пож.
если вы про MemoryBarrier то это фактический сброс кеша с последующим объявлением его не действительным- вот и вся синхронизация, или там есть еще какое то шаманство?Нет. Барьер - это не "сброс кэша". Никакого "сброса кэша" не существует. Если забыть про JIT, и рассматривать только железо, то "барьерные инструкции" (напр. с префиксом lock на x86), делают две вещи:
1) При записи, перед тем как ее завершить, ядро ждет, пока store buffer его кэша не флашнется, то есть пока информация о предыдущих записях, которые были сделаны этим ядром, но пока что видны только ему (см. store forwarding), не станет "видна" другим ядрам. "Видна" - это значит, что другие ядра получили запрос на инвалидацию измененных ячеек в своих кэшах.
2) При чтении, перед тем, как ее осуществить, ядро должно обработать свою invalidate queue, то есть применить все запросы на инвалидацию, полученные ранее от других ядер, но еще не обработанные.
В этом и есть суть "частичной синхронизации" кэшей разных ядер при выполнении бареров.

Кроме того, барьеры запрещают ядрам делать out-of-order execution в их окрестностях.