Потоки

1 - Насколько медленно создаются новые потоки?

Чуть быстрее чем новый процесс.

2 - Можно ли создать поток в остановленном состоянии и без указания функции, а потом указать функцию которую нужно исполнить в отдельном потоке и запустить поток?

В общем случае - нет.

3 - Есть ли кроссплатформенная библиатека для удобной работы с потоками?

Смотря где. В C начиная с C11 есть треды, но я не слышал про реализацию этой части стандарта. Для C++ есть boost::thread и std::thread.

Пишу программу, задумался о том чтобы сделать её многопоточной
хочу узнать ответы на некоторые вопросы, чтобы знать изучать мне их или нет

Попробуй лучше изучить Go.

http://www.amazon.com/PThreads-Programming-Standard-Multiprocessing-Nutshell/...

1. spawn_link отрабатывает молниеносно.

2.

P = spawn_link(fun() -> receive {fn, Fn, Args} -> Fn(Args) end end),
P ! {fn, fun(N) -> io:format("~w~n", [N]) end, 42}.

3. Зачем библиaтека, если есть эрланг?

Есть OpenMP - хорошо поддерживается компиляторами, прост в изучении, для простых задач распараллеливания вполне работает.

Попробуй лучше изучить Go.

++

с потоками ниразу не работал

Тогда готовься наступить на массу совершенно неожиданных и неочевидных граблей. Для начала прочитай хотя бы про http://en.wikipedia.org/wiki/Memory_barrier и про http://en.wikipedia.org/wiki/Monitor_(synchronization)

1 - Насколько медленно создаются новые потоки?
2 - Можно ли создать поток в остановленном состоянии и без указания функции, а потом указать функцию которую нужно исполнить в отдельном потоке и запустить поток?
3 - Есть ли кроссплатформенная библиатека для удобной работы с потоками?

http://en.wikipedia.org/wiki/Thread_pool_pattern
http://stackoverflow.com/questions/19500404/how-to-create-a-thread-pool-using...

1 - Насколько медленно создаются новые потоки?

Зависит от реализации. В общем случае считай что если тебе нужно создавать больше единиц потоков в секунду ты что-то делаешь не так.

2 - Можно ли создать поток в остановленном состоянии и без указания функции, а потом указать функцию которую нужно исполнить в отдельном потоке и запустить поток?

Нет, в этом нет смысла. Но вообще можно указать функцию, которая сразу после запуска усыпит поток, и будет ждать пока снаружи не передадут функцию для выполнения.

3 - Есть ли кроссплатформенная библиатека для удобной работы с потоками?

Потоки - ядерная ипостась, поэтому библиотека тесно привязана к ядру и кроссплатформенной быть не может по определению. Но её интерфейс стандартизирован POSIX, поэтому код использующий POSIX потоки будет кроссплатформенным. Есть масса кроссплатформенных обёрток над потоками. Самая очевидная - плюсовые std::thread.

Пишу программу, задумался о том чтобы сделать её многопоточной

А зачем? Ты уверен, что это даст профит?

mix_mix

Попробуй лучше изучить Go.

nanoolinux

spawn_link отрабатывает молниеносно.

Я специально не указывал ЯП на котором пишу, чтобы было понятно, что меня не интересует конкретные реализации на определенных языках, а интересует возможность реализации этих действий на уровне системных вызовов.

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

c11 уже вроде как implemented

c11 уже вроде как implemented

Не полностью. Треды находятся в дополнении, на которое всем плевать. По крайней мере в gcc 4.9 их нет.

интересует возможность реализации этих действий на уровне системных вызовов.

Таненбаум. «Операционные системы» - сразу даст тебе понимание , что такое и потоки и примитивы синхронизации.

а дальше уже мануалы по конкретным системам и нюансы реализации

на уровне системных вызовов.

Ну так man clone тогда. Ну и man futex до кучи.

Не полностью. Треды находятся в дополнении, на которое всем плевать.

очень жаль :(
пойду посмотрю как там у clang дела с этим...

возможность реализации этих действий на уровне системных вызовов

Дёргается сисколл clone с CLONE_THREAD, но наверное это не то, что ты хотел знать. Тебе же предлагают изучить на порядок более продвинутую практику использования зелёных потоков (как в уже предложенных go и erlang).

У меня даже мыслей не было, что все будет гладко и без граблей.

Зависит от реализации. В общем случае считай что если тебе нужно создавать больше единиц потоков в секунду ты что-то делаешь не так.

Задачи в нескорых местах в теории могут быть сильно распаралеленны, потоки в одно и тоже место не записывают, но нескорые могут читать с одного места, в зависимости от входных данных потоков может быть вплоть до 1000, поэтому я и задал 2-й вопрос предполагая, что новые потоки создаются медленно.

Но вообще можно указать функцию, которая сразу после запуска усыпит поток, и будет ждать пока снаружи не передадут функцию для выполнения.

Это уже вселяет надежду.

В данный момент профита особого не будет, но учитывая нарастание количества ядер и процессоров в ПК и мобилках, есть смысл её расспаралелить, если я её сейчас допишу как однопоточное приложение, то в будущем чтобы её расспаралеливать придется приложить гораздо больше усилий.

для простых задач распараллеливания вполне работает.

Не для простых задач, а для всего. Вменяемых аналогов на сегодняшний момент нет вообще.

А толку?

Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-4) 
dron@gnu:~$ 

ээ... не понял?

https://www.linux.org.ru/forum/development/11095911?cid=11097074 (комментарий)

зелёных потоков

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

данных потоков может быть вплоть до 1000,

проблемы начинаются намного позже. 1000 потоков это даже 10 лет назад не было проблемой.

Не готово ещё.

++

лучший из возможных ответ на просьбу изучить Go )

Ты сначала определись, какого параллелизма тебе хочется: по данным, или функционального. Если по данным, то используй всякие parallel_for из tbb или OpenMP. Если ты хочешь функционального параллелизма, то тебе помогут std::thread, boost::thread, QThread

а зеленые потоки не для этого созданы

В том числе и для этого, продолжай изучать.

Все спасибо за ответы. Ответом стали: man clone, man futex, NPTL

Задачи в нескорых местах в теории могут быть сильно распаралеленны, потоки в одно и тоже место не записывают, но нескорые могут читать с одного места, в зависимости от входных данных потоков может быть вплоть до 1000, поэтому я и задал 2-й вопрос предполагая, что новые потоки создаются медленно.

Количество потоков должно зависеть от количества ядер, а не от входных данных.

Все спасибо за ответы. Ответом стали: man clone, man futex, NPTL

Ты просил кроссплатформенное. Перечисленное - линуксня.

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

При нормальной реализации (не как в пистоне) green threads мапятся на os threads как M к N.

Так для работы с ними используется glibc, которая является кроссплатформенной, или нет?

Вот glibc - да, кроссплатформенный. Но на других системах он использует другие реализации потоков.