подскажите - а как и насколько принципы использования тредов в Java отличаются от нормальных языков типа C?

Прынцыпы они больше от ОС зависят, даже на С.

переформулировал вопрос.

1) В Java очень строго и детально описаная модель памяти, работающая на любом железе одинаково. По крайней мере согласно правилам в тех местах где даются гарантии

2) Обычно треды используют где уверены что необходима постоянная работа этого треда. Но в 90% случаях все думают в терминах выполнения задач (task) паралельно. И запускают не треды, а просто отправляют Runnable или лямбду в ExecutorService. Это быстрее, дешевле, управляемее и короче

3) В Java очень много готовых примитивов, много из них lock-free. Лучше поискать готовую concurrent lock free структуру данных, чем lock с обычным Map. Лучше использовать готовые atomics или даже LongAdder, чем городить свой велосипед.

4) Для многих сценариев можно применить Fork-Join Pool - более умная абстракция для параллелизма, умеет предотвращать всякие голодания потоков, когда одна задача вроде-как блокирующе ждет другую

на современных линуксах java-треды реализованы через нативные треды. На осях где нет своих тредов (н.р java 1.1+solaris) используются свои зеленые треды. На линуксах с NTPL все треды имею один process ID, но разные thread ID (поле LWP в выхлопе ps -eLf). На говне мамонта с linuxthreads они имеют разные process ID. Сам Thread емнип написан на C++ через JNI.

Ок. Это ближе к делу.

Ну вот скажем - а как обстоят дела с аффинити и подобным? Например игры с аффинити воможны или целесообразны?

А с инвалидацией и промахами кешей?

ни разу не пользовался, поэтому не буду отвечать ересь

а вот возьми и попробуй! и прям сюда результаты теста!

http://stackoverflow.com/questions/1888160/distinguish-java-threads-and-os-th...

По пункту номер три. У меня есть, например ArrayList и HashSet. Треды работают и, на каждой внутренней итерации, сваливают туда данные. Работа с ними вынесена в одну единственную функцию, там три строчки, каждая работает только с этими коллекциями (вычесть из множества и добавить новые элементы), которая объявлена как synchronized. Профилировщик показывает, что блокировок тредов нет. Так делать глупо? Стоит писать на основании примитивов? В этом конкретном случае необходимо, чтобы все действия выполнялись последовательно и вклинивания из других тредов не происходило, так что примитивы мне, наверное, не помогут, но в общем случае примитивы лучше synchronized?

Спасибо - интересно

Если в рамках одной операции ArrayList и HashSet всегда модифицируются вместе, то наверное вариант с synchronized подойдет лучше всего. А если бы речь шла например только о HashSet, то тогда вместо полной блокировки имело бы смысл взять ConcurrentHashMap (для ArrayList — CopyOnWriteArrayList).

Ясно. Спасибо.

В Java треды работают так, как написано в спецификации Java. На C нет спецификации на треды и всё работает так, как написано в мануале по твоему процессору.

В целом да, суть та же и отличается не сильно.

Ну вот скажем - а как обстоят дела с аффинити и подобным? Например игры с аффинити воможны или целесообразны?

возможны, но вроде нормальных библиотек для этого нет, целесообразность зависит от твоего алгоритма, естественно.

А с инвалидацией и промахами кешей?

а что с ними? можно как промахнуться, так и не промахнуться, зависит от алгоритма, в восьмой джаве добавили @Contended, если тебе это интересно.

а при чем здесь какие-то непонятные цыпы?

управляемее

ох, а там EventQueue.invokeaAndWait и все хана всему executor

Не понял

Из коробки средств для настройки thread affinity нет. Говорят это кому-то бывает нужно, но я не видел такого.

На C нет спецификации на треды

Начиная с С11, что-то есть

отличается, и довольно сильно, лучше почитать книжку

очень легко получить deadlock