Вы всё перепутали :) Элементарные операции и есть низкоуровневые :) Выделение и освобождение памяти это тоже элементарные операции, и поэтому они низкоуровневые.
Это ведь уже элементарные операции, которые дальше никуда не объединить.
Наоборот :) Элементарные операции нельзя разложить :) А объеденять их можно сколько душе угодно. Элементарные операции для того и нужны, что-бы их объеденять в более сложные :)
Boost.Thread - это всего навсего надстройка над общей частью между pthread и Win32 API. Никаких новых абстракций, которых нету в PTHREAD-ах она не даёт.
Я не говорю о том, что автоматически распаралеливать надо существующий код. Я говорю о том, что автоматически надо распаралеливать код в котором определённым образом задекларированны зависимости. А этим уже может и ВМ заниматься и фреймворк.
Я и не говорю что надо отказываться от потоков. А тем более в ОС. Я говорю что не надо потоками и синхронизацией напрягать высокоуровневых программистов.
Я-же какраз об этом и говорю, что мы имеем именно тот случай, когда одна пропоганда со стороны Intel-а (какой бы она агресивной не была) ничем им не поможет, а надо всерьёз браться за решение этой задачи.
Однако никакие концепции и абстракции не решат проблему синхронизации доступа к ресурсам и исключения взаимоблокировок. Конечно можно разработать общий способ, как например в C# ключевое слово lock(...). Однако всё равно компилятор никогда сам не определит точные блоки кода, на которые надо ставить блокировку, т.е. критические секции сам не расставит. Это оочень интеллектуальная задача.
Проблема в том что для решения этой задачи нужна информация обо всех зависимостях в системе, и у программиста какраз такой информации нету, а у компилятора\виртуальной машины есть. Более того, такие зависимости могут появляться во время выполнения, и виртуальная машина сможет разрешать такие ситуации.
Поэтому эту задачу должен решать не программист, а именно виртуальная машина.
Вообщем есть 2 основных направления обеспечения взаимодействия между потоками или процессами:
1. data sharing (для разных процессов он тоже возможен и будет реализован через shared memory + межпроцессорные блокировки)
2. message passing
Смысл моего топика в том что-бы оградить высокоуровневого программиста и от обеих типов низкоуровневых стратегий синхронизации. Программиста в идеале не должно волновать как именно будет опеспечиваться парралелизм, за счёт потоков или за счёт процессов. И как именно обеспечивается синхронизация.
Кроме императивного, я знаком и с функциональным программированием и с логическим. В одной статье обо всём не напишешь, поэтому писал о мейнстриме - а именно, об императивной модели вычислений.
На самом деле я просто не знал реальную причину, по которой Intel решили клепать многоядер, отказавшись от того что-бы гнать частоту. Вернее, я знал, что это какая-то невозможность обусловленная законами физики, но не знал что это именно предел воздушного охлаждения, поэтому писать не стал. Но с вами согласен, что упомянуть об этом нужно.
Поток - это низкоуровневая сущность. Существует дизайн паттерн "активный объект", и вот он уже предендует быть высокоуровневым. Высокоуровневость обеспечивается тем, что не сказанно, должен ли этот паттерн быть реализован при помощи отдельного потока в том-же процессе, отдельного процесса, или вообще процесса в удалённой среде.
То, о чём Вы говорите называется тиранией большинства. Демократия обычно приводит к такому виду тирании. Если я не ошибаюсь, у Ричарда Фарсона в книге "Менеджмент Абсурда" есть пример, когда в usenet-е хотели создать группу для обсуждения культуры Тибета. Провели голосование, но группа создана небыла. Так как большинство жителей Китая не считает Тибет отдельной страной, они не видят причин почему култура Тибета должна обсуждаться отдельно от культуры всего Китая.
Я читаю книги с телефона Nokia E70 и мне это удобнее делать, чем читать бумажные книги. Наверное причина в том, что у телефона подсвечивается экран и очень удобно читать в сумерках - экран получается более контрастным чем окружающий фон.
Следовать особо ничему не нужно (сужу по себе, я текст книги уже не очень помню). Для того что-бы исчезло желание курить и что-бы оно не появилось вновь достаточно просто прочитать книгу. (так было у меня и у тех друзей которым я посоветовал бросить лёгким способом)
Единственное чему надо следовать это 2 вещи - нужно прочитать книгу от начала до конца, не растягивая это занятие на неопределённый срок, и желательно не бросать курить до того момента пока Вы не дочитаете книгу до конца, даже если желание курить пропадёт на середине книги.
Для того что-бы бросить курить при помощи "лёгкого способа" нужно просто дочитать книгу до конца :) Об этом написанно во введении если я не ошибаюсь :) Не нужно выполнять никакие упражнения или следовать методикам. Просто надо прочитать книгу от начала до конца (при этом курить по ходу чтения книги можно). Причём книга не большая, желательно не растягивать чтение а прочитать хотя-бы за 5 заходов.
Я бросил курить "лёгким способом" и не курю уже 2 года (хотя до этого курил 8 лет). Среди моих друзей 2 человека тоже бросили лёгким способом. Всего я знаю человек 10 знакомых которые бросили этим способом и сейчас не курят и 1-ого который бросил но через год начал курить опять. Я думаю что способ примерно так и срабатывает в 9-ти из 10-ти случаев. До прочтения книги одному из моих друзей казалось что его "накрывает физика" (физиологическая зависимость) и бросить курить он ну никак не может, а после прочтения бросил элементарно.
Вообщем если у вас есть желание бросить курить то попробовать стоит. Тем более что никаких дополнительных усилий кроме как просто прочитать книгу от вас не требуются.
Тот-же эффект возникает если у десктоп приложения в меню куча разных пунктов. Возникает иллюзия что у этого приложения оргомное количество функциональности всякой разной. Проходит так же через пару дней работы с приложением.
Наоборот :) Элементарные операции нельзя разложить :) А объеденять их можно сколько душе угодно. Элементарные операции для того и нужны, что-бы их объеденять в более сложные :)
4. либо этим занимается фреймворк.
:)
Проблема в том что для решения этой задачи нужна информация обо всех зависимостях в системе, и у программиста какраз такой информации нету, а у компилятора\виртуальной машины есть. Более того, такие зависимости могут появляться во время выполнения, и виртуальная машина сможет разрешать такие ситуации.
Поэтому эту задачу должен решать не программист, а именно виртуальная машина.
1. data sharing (для разных процессов он тоже возможен и будет реализован через shared memory + межпроцессорные блокировки)
2. message passing
Смысл моего топика в том что-бы оградить высокоуровневого программиста и от обеих типов низкоуровневых стратегий синхронизации. Программиста в идеале не должно волновать как именно будет опеспечиваться парралелизм, за счёт потоков или за счёт процессов. И как именно обеспечивается синхронизация.
Почитаю об этом по подробнее и поправлю статью.
Единственное чему надо следовать это 2 вещи - нужно прочитать книгу от начала до конца, не растягивая это занятие на неопределённый срок, и желательно не бросать курить до того момента пока Вы не дочитаете книгу до конца, даже если желание курить пропадёт на середине книги.
Я бросил курить "лёгким способом" и не курю уже 2 года (хотя до этого курил 8 лет). Среди моих друзей 2 человека тоже бросили лёгким способом. Всего я знаю человек 10 знакомых которые бросили этим способом и сейчас не курят и 1-ого который бросил но через год начал курить опять. Я думаю что способ примерно так и срабатывает в 9-ти из 10-ти случаев. До прочтения книги одному из моих друзей казалось что его "накрывает физика" (физиологическая зависимость) и бросить курить он ну никак не может, а после прочтения бросил элементарно.
Вообщем если у вас есть желание бросить курить то попробовать стоит. Тем более что никаких дополнительных усилий кроме как просто прочитать книгу от вас не требуются.