LINUX.ORG.RU

POSIX threads vs std / boost

 ,


0

4

Из темы Отладка ошибки многопоточности

Назовите мне хоть одну реальную причину, по которой имеет смысл использовать в проекте на C++ POSIX threads вместо std::thread / boost::thread.

Пока я вижу только две:

  • Запрет использования C++11 / C++14 / C++17 (старый компилятор, требование компании etc)
  • Старый проект, в котором уже написаны свои обёртки над POSIX thread'ами

Кто ещё в здравом уме будет скатываться до API системы, когда в языке есть более высокоуровневое средство для решения той же задачи? Это всё равно, что советовать для проектов под Windows использовать CreateThread / _beginthread / _beginthreadex вместо всё тех же std / boost.

Баги? На какие лично вы натыкались?

Производительность? Обычно проблемы производительности, связанные с синхронизацией потоков, вызваны хреновой архитектурой, а вовсе не тем, что используется std::mutex вместо pthread_mutex_t.



Последнее исправление: b0r3d0m (всего исправлений: 1)

Ответ на: комментарий от anonymous

про std::sort vs qsort

При чем тут компилятор? В любой реализации qsort ввиде макроса или header-only функции на сишке все так же инлайнится.

Только у него нет информации о типах и он так же, как и незаинлайненный, дёргает memcpy/memmove, вместо вызова swap (iter_swap), который может быть для данного типа эффективнее memcpy-суходрочки (не говоря уже о том, что корректнее).

utf8nowhere ★★★
()
Ответ на: комментарий от anonymous

Но вопрос в том, где проще писать низкоуровневый код. На сишке конечно же проще писать низкоуровневый код, ибо она проще, прозрачнее и ближе к железу.

за всех не скажу, но мне лично именно низкоуровневый код легче писать на плюсах. ибо он позволяет автоматизировать любовь с байтами на уровне, который мне необходим. тот же std::string не использую там, где нужен перформанс. но использую обёртку над char *, с умными в дебаге итераторами, size. результат тот же, но писать мне удобнее. а есть куски, которые только на макросах на C в виде библиотеки можно сделать. вот тут точно C для меня непригоден.

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

dzidzitop ★★
()
Ответ на: комментарий от tailgunner

т.е. при использовании async нужно что-то знать про когерентность кэшей процессора? которых и в языке-то нет в принципе. абстракция не протекает ну совсем.

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

Изменение глобальных переменных без синхронизации доступа - это либо понты, либо ошибка.

т.е. при использовании async нужно что-то знать про когерентность кэшей процессора?

У тебя с чтением проблемы?

tailgunner ★★★★★
()
Ответ на: комментарий от utf8nowhere

C++ это как южная корея, C - как северная. на C сложно писать не низкоуровнево.

dzidzitop ★★
()
Ответ на: комментарий от utf8nowhere

Ну давай, просвети нас, как же надо пользоваться rwlock.

Ты умеешь читать? Так, чтобы за мьютекс не боролись постоянно 2+ нити.

vzzo ★★★
()
Ответ на: комментарий от vzzo

Ты умеешь читать?

Тебе тот же вопрос.

Точнее, так: ты умеешь читать что написано, а не выдумывать ненаписанное?

utf8nowhere ★★★
()
Ответ на: комментарий от anonymous

До поры до времени что-то знает, но пользуется только sizeof() этих типов и всё в конце концов превращается в побайтовый/пословный swap через char*.

Ты правда не понимаешь, что sizeof() это не единственная характеристика типа?

utf8nowhere ★★★
()
Ответ на: комментарий от utf8nowhere

это не единственная характеристика типа?

Покажи мне пример сишной программы, в которой понадобилось бы что-то кроме простого побайтового копирования? В си в 99% случаев ты имеешь простые типы данных, побайтово выровненные структурки и юнионы.

anonymous
()
Ответ на: комментарий от anonymous

Покажи мне пример сишной программы, в которой понадобилось бы что-то кроме простого побайтового копирования?

Покажи мне пример сишной программы из которой можно вызывать std::sort.

utf8nowhere ★★★
()
Ответ на: комментарий от anonymous

А в сишке есть другие типы?

Речь шла о том, что можно юзать C++. А там другие типы будут быть.

Ты пришёл мне рассказать, что для POD qsort может быть так же быстр, как std::sort? Спасибо, очень нетривиальные сведения.

utf8nowhere ★★★
()
Ответ на: комментарий от utf8nowhere

Покажи мне пример сишной программы из которой можно вызывать std::sort.

При чем тут std::sort?

Изначальный тезис был про:

компилятор может иметь больше информации о типах и агрессивнее инлайнийть. погугли про std::sort vs qsort

Я сказал, что сищный(!) компилятор все тоже прекрасно инлайнит и дело не в сишке, а в реализации qsort, и привел пример.

anonymous
()
Ответ на: комментарий от utf8nowhere

Речь шла о том, что можно юзать C++.

Нет, речь шла именно о производительности си vs си++.

на C++ можно писать такой же по производительности код, как на C, если не более производительный (т.к. компилятор может иметь больше информации о типах и агрессивнее инлайнийть. погугли про std::sort vs qsort).

anonymous
()
Ответ на: комментарий от anonymous

При чем тут std::sort?

При том, что я про него писал. Ты выкинул часть моего сообщения, оставив только про «qsort» и «инлайнит» и начал мне тривиальщину толкать с банальным выводом: POD-типы swap-аются одинаковым образом в C и C++.

utf8nowhere ★★★
()
Ответ на: комментарий от anonymous

А лучше этот.

Можно ещё написать qsort-макрос с соглашением, что пользователь предоставит функцию типа __mytype_swap(), а qsort будет её дёргать. И после этого поздравить себя с переизобретенем своего, нигде никем более неиспользуемого, name manglinga.

Никто не спорит, что возможности цепепе можно имитировать. Только зачем имитировать, когда есть готовое.

utf8nowhere ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.