>и как вы собираетесь передать хотя бы 1 бит информации если у вас нет разделяемого массива бит

Как в "передать яблоко". Если переданое _не_ осталось у "меня", оно _не_ разделяемое.

>> и как вы собираетесь передать хотя бы 1 бит информации если у вас нет разделяемого массива бит ?

> Сокет не является чем-то разделяемым.

Какого ляда вы дружно в сеть полезли ? Вы что считаете, что если на сетевой кабель не напаяна планка памяти, то разделяемой памяти нет? Тогда можете объяснить каково ляда TCP занимается поддержкой синхронности __общего__ для двух процесса исполнения канала(потока ввода вывода)?

Вам, что продемонстрировать deadlock на сокетах ?

Вы что считаете что если вы сериализуете обмен данными между потоками исполнения, то у вас все проблемы пропадут ?

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

Ради развлечения попробуйте написать простую вещь - два паралельных блока кода которые исполнятся _одновременно_, или на худой конец с разницей не более чем n единиц времени, и докажите, что оно так и есть. Сокеты разрешается использовать :)

>> и как вы собираетесь передать хотя бы 1 бит информации если у вас нет разделяемого массива бит

> Как в "передать яблоко". Если переданое _не_ осталось у "меня", оно _не_ разделяемое.

Очень плохой пример, но на нем поясню :(

"полность"(подходящей для данного случая) неразделяемой передачей яблока - было бы - если ты не видишь куда передаешь, а другой не видит откуда берет, а это уже недетерминированный канал связи ... Проблемы многопоточности по сравнению с этим - детский лепет.

Сам садись два, вот Баня Л.Н. Толстого: http://clubsaun.ru/articles/articles_93.html

..never be able to create a correct threaded program in C++ or Java, despite years of study. It's just too hard... почему он не написал что это невозможно???

>Льва Толстого не трожь! Почитай хороших рассказов, "Баня" например,

емнип, автор сего креатива - А.К. Толстой?

Что интересно, мoя ex - професор в известном университете, так она тоже и Жаву и ЦПП преподаёт много лет, но как программист она на очень среднем уровне. Так что ничего странного, что товарисч не осилил.

аха, а ещё про питона рассуждать взялись :(

> Сам садись два, вот Баня Л.Н. Толстого: http://clubsaun.ru/articles/articles_93.html

На сарае известно что написано... Погули дальше. Л.Н. к этому рассказу отношение не имеет, это глюк контент-менеджеров.

> Что интересно, мoя ex - професор в известном университете, так она тоже и Жаву и ЦПП преподаёт много лет

А как кстати прелмет называется? "ООП для мазохистов"?

>>> и как вы собираетесь передать хотя бы 1 бит информации если у вас нет разделяемого массива бит ?

>> Сокет не является чем-то разделяемым.

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

> Ради развлечения попробуйте написать простую вещь - два паралельных блока кода которые исполнятся _одновременно_, или на худой конец с разницей не более чем n единиц времени, и докажите, что оно так и есть. Сокеты разрешается использовать :)

[бред поскипан]

я вполне корректно указал, что сокет не является "разделяемым массивом бит". с вашими аргументами я не спорю, но они никоим образом не опровергают мои.

>- "Smart Libraries", "встроенный" context help - все это связано с RTTI, Reflection: "I want the component to tell me what it does, how to use it, and even to reach out and wire itself into my program (for example, by looking at the available variables and putting candidates into its argument list, with drop-down menus that allow you to select appropriate alternatives)."

Как он ЭТО собрался в ЯЗЫК встроить? А так в той же IntellyJ IDEA Smart автокомплишен уже давно и прекрасно выбирает классы по всем подключенным либам: просто пишешь желаемое название метода и среда подсказывает, в каких библиотеках такой метод реализован, что хочет в таком случае Эккель? У него что, с продаж TiJ 4Ed $250 не скопилось на покупку семерки?

> святой дух ?

Канал обмена

> нет разделяемого массива бит ?

Это не обязательно память.

>заинтересовался ... киньте ссылку на Erlang scalability

На, пожалста: http://weblog.plexobject.com/?p=1576

http://lambda-the-ultimate.org/node/1615

> В идеале хочется иметь такой спецязык, чтоб умел и с матрицами эффективно работать, и ФП там было, и встроенные примитивы для распределённых вычислений.

Ну дыкть, я помню, лисперы в свое время это показывали. ФП там есть by design, "работать с матрицами" -- пишется за день-два, подозреваю, что уже давно сделано, а для распредвычислений они там какие-то ссылки приводили, но мне было не нужно, потому я не сильно ковырял...

> Бруно библию не переписывал и не говорил, что Христос просто человек, а это церкви -- сами знаете что :)

Бруно участвовал в работе тогдашних сатанинских обществ Европы, а ведь признание сатаны -- это тоже христианские бредни ;-)

Разделяемый - это не обязательно один единственный разъединственный объект(сущность) находящийся в адресном пространстве памяти обоих потоков выполнения, но обязательно - объект(сущность) - который "принадлежит", "синхронен", с состоянием и действиями в обоих потоках выполнения (к слову - с чего это вы уверены, что тот массив бит с которым вы работаете по ссылке в памяти уникален ?).
Без такого обьекта вы детерминированную передачу сообщений не построите принципиально. А так как в лубом случае у этого объекта будет состояние не менен одного бита - то и получится - разделяемая память.
Суть всех этих распинаний только в том что-бы показать, что утверждение, что
многопоточная синхронизация, а она обязана быть детерминированной, возможна без разделямой памяти (более точно и общо - разделяемой сущности обладающей состоянием) - чушь

ниасилил. много букаф :)

>Суть всех этих распинаний только в том что-бы показать, что утверждение, что многопоточная синхронизация, а она обязана быть детерминированной, возможна без разделямой памяти (более точно и общо - разделяемой сущности обладающей состоянием) - чушь

Повесь параллельные задачи на разные машины. Там не будет разделяемой памяти. На одной машине ты сделаешь то же самое через юниксовый сокет

>> святой дух ?
> Канал обмена

Это так святой дух теперь называется ? :)
канал объмена бесплотен и не содержит ни бита ?

>> нет разделяемого массива бит ?
> Это не обязательно память.

то что хранит,содержит массив бит есть память

>>Суть всех этих распинаний только в том что-бы показать, что утверждение, что многопоточная синхронизация, а она обязана быть детерминированной, возможна без разделямой памяти (более точно и общо - разделяемой сущности обладающей состоянием) - чушь

>Повесь параллельные задачи на разные машины. Там не будет разделяемой памяти. На одной машине ты сделаешь то же самое через юниксовый сокет

___синхронизация___ ! синхронизация не возможна без детерминированного обмена сообщениями, детерминированный обмен сообщениями не возможен мез разделяемой сущности (память уже боюсь произносить - слишком многих клинит на самсунговских планках)

> ниасилил. много букаф :)

тренируйся :)

> Это так святой дух теперь называется ? :)

Ну, если Вам так хочется...

> канал объмена бесплотен и не содержит ни бита ?

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

Так понятно?

> то что хранит,содержит массив бит есть память

Порты ввода-вывода -- это память?

"Don't feed the trolls" (c)

>Смотри - предположим, что две сущности полностью изолированны друг от друга (не содержат ничего общего), эти сущности/системы по уже заданому требованию являются замкнутыми и изолированными по отношению друг другу, а значит не могут обмениваться ___ничем___. Если допустить существование святого духа, то все отлично, но если нет , то ответте на вопрос - как информация преодолеет барьер между системами, с помощью магических заклинаний?

Сэру стоило бы быть поближе к реальности... к этой реальности

>Молодец, ты заработал твёрдое "хорошо" о "физической" картине мира. Только, извини, нефизический мир - это мистика. Добро пожаловать в реальность, мой молодой друг.

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

Так что там, насчет святого духа?

Прикольно... вроде как ответ мне, а среди обширных цитат - ни одного моего слова :D

> синхронизация не возможна без детерминированного обмена сообщениями,

В общем случае верно, но

> детерминированный обмен сообщениями не возможен без разделяемой сущности

не совсем так. Известны классическая задачи "синхронизации" ещё в докомпьютерную эпоху, например, солдат при манёврах на параде, когда единственным источником сообщения для синхронизации является поведение товарища.

вот любопытный способ программировать распараллеленную числодробилку на C++ на основе однопоточной версии:

http://www.ddj.com/hpc-high-performance-computing/199902702;jsessionid=OM5NLI...

Вкратце: сама расчетная часть из однопоточной версии загоняется в объекты "программа", написанные на C++, компилируемые бекендом чем-то вроде JITа и исполняемые на целевом ядре/GPU/итп. Это крутится на своей платформе, причем за счет JITа под платформой вроде бы даже на одном ядре быстрее чем однопоточная версия. Сама платформа это библиотека на С++ + кодогенератор под разные целевые процессоры.

2Casus ***** (*) (17.09.2007 0:13:22):

>> Это типа приговор самому себе как программисту. Армия дворников ждёт новобранца!

Помнится, никто иной, как Вы, батенька, любили говаривать 'форкали и будем форкать' ;-)

Плиа, народ, смотрите код ядра. Конкретно смотреть код функции _clone(). THREAD'Ы И FORK'И В ЯДРЕ LINUX ЭТО ОДНО И ТО ЖЕ! РАЗНИЦА В ТОМ, ЧТО THREAD'Ы ИСПОЛЬЗУЮТ КАКИЕ-ТО ОБЩИЕ РЕСУРСЫ ДЛЯ СОБСТВЕННОЙ СВЯЗИ.

P.S.: Можете верить, можете нет, но я лично разработал двиг с реализацией многопоточности. На разработку и отладку (отлатка нитей - ЗЛО) ушло около двух месяцев. P.P.S: Очень часто можно в прогах обойтись и без нитей.

>P.S.: Можете верить, можете нет, но я лично разработал двиг с реализацией многопоточности

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

>>P.S.: Можете верить, можете нет, но я лично разработал двиг с реализацией многопоточности

>Мы все изготовили идол анонимуса и молимся на него каждый раз, когда читаем слово thread

Нужно еще приносить жертвы :D

> THREAD'Ы И FORK'И В ЯДРЕ LINUX ЭТО ОДНО И ТО ЖЕ!

ЭТО ПРОБЛЕМЫ ЯДРА LINUX. В БОЛЕЕ ДРУГИХ ОС ЭТО НЕ ТАК!

>> THREAD'Ы И FORK'И В ЯДРЕ LINUX ЭТО ОДНО И ТО ЖЕ!

> ЭТО ПРОБЛЕМЫ ЯДРА LINUX. В БОЛЕЕ ДРУГИХ ОС ЭТО НЕ ТАК!

БЛОНДИНКИ НА ЛОРЕ! АААА!!!

> не совсем так. Известны классическая задачи "синхронизации" ещё в докомпьютерную эпоху, например, солдат при манёврах на параде, когда единственным источником сообщения для синхронизации является поведение товарища.

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

>обязательно - объект(сущность) - который "принадлежит", "синхронен", с состоянием и действиями в обоих потоках выполнения

О! Ключевое слово "потоках выполнения". То есть "сущность" то нужна, но она не обязательно доступна(принадлежит, синхронна, и т.д.) другим "потокам выполнения". Ибо вполне можно заблокировать "выполнение" остальных потоков "железными" средствами при обращении одной из сущностей "туда".

Поправка

s/одной из сущностей/одного из потоков/

>солдат Вася синхронизирует свой строевой шаг с солдатом Петей

Кстати, ntpd вполне себе синхронизируются по недетерминированому каналу.

> О! Ключевое слово "потоках выполнения". То есть "сущность" то нужна, но она не обязательно

--> доступна(принадлежит, синхронна, и т.д.) другим "потокам выполнения". Ибо вполне можно заблокировать "выполнение" остальных потоков "железными" средствами при обращении одной из сущностей "туда".

первое - мы ведь говорим о равноправных потоках выполнения ? :)
а тут логическая не увязка
если сущность не доступна(не принадлежит, не синхронна, и т.д.) другим "потокам выполнения"
то никагого обращении одной из сущностей "туда" не будет

>> солдат Вася синхронизирует свой строевой шаг с солдатом Петей

> Кстати, ntpd вполне себе синхронизируются по недетерминированому каналу.

интересный вопрос, но ведь и TCP синхронизируется по недетерменированному каналу :)

тут красивая шутка - синхронизация невозможна без синхронизации, выйти из которой можно если только - синхронизация невозможна без разделяемой сущности :)

>если сущность не доступна другим "потокам выполнения" то никагого обращении одной из сущностей "туда" не будет

Нельзя путать принадлежность сущности со знанием имени(адреса) оной. Возьмём ту же память. Пока поток не попытается туда обратиться, она ему _не_ принадлежит - её может и не быть вовсе (высвопили например). Факт принадлежности "устанавливается" в (и на) момент обращения, и тут уже железо постарается, чтобы второго такого же не произошло, пока не закончится первое(наверное можно сделать по другому, но получится фигня какая-то, или квантовый компютер). Таким образом даже обычная "разделяемая память" не является строго говоря "синхронно принадлежащей 2м потокам" - в соответствующих масштабах (слово-такт).

>но ведь и TCP синхронизируется ... тут красивая шутка - синхронизация невозможна без синхронизации

А если учесть, что ntp работает по никак не синхронизируемому UDP?

> THREAD'Ы И FORK'И В ЯДРЕ LINUX ЭТО ОДНО И ТО ЖЕ!

ЭТО ПРОБЛЕМЫ ЯДРА LINUX. В БОЛЕЕ ДРУГИХ ОС ЭТО НЕ ТАК!

В более других ОС процессов вообще нет - там только пачки тредов. Вроде бы даже возможно вообще удалить эту пачку (именемую процессом), сохранив сами треды чтобы сделать троянского коня невидимым к примеру. Получается та же фигня что и в линуксе, вид сбоку.

> Нельзя путать принадлежность сущности со знанием имени(адреса) оной. Возьмём ту же память. Пока поток не попытается туда обратиться, она ему _не_ принадлежит - её может и не быть вовсе (высвопили например). Факт принадлежности "устанавливается" в (и на) момент обращения, и тут уже железо постарается, чтобы второго такого же не произошло, пока не закончится первое(наверное можно сделать по другому, но получится фигня какая-то, или квантовый компютер). Таким образом даже обычная "разделяемая память" не является строго говоря "синхронно принадлежащей 2м потокам" - в соответствующих масштабах (слово-такт).

мы по разному понимаем слово "принадлежит"
ты - это наличие признака владения
я - возможность оперирования над
с моей позиции для синхронизации двух потоков нужно предоставить им обоим возможность для оперирования над единой сущностью пусть даже виртуальной и это будет совместное владение, даже если оно взаимоисключающее. Это __необходимо__, но конечно же недостаточно.
Достаточно, будет когда будет существовать взяимоисключающее владение - ваше.

>> но ведь и TCP синхронизируется ... тут красивая шутка - синхронизация невозможна без синхронизации

> А если учесть, что ntp работает по никак не синхронизируемому UDP?

просто, две точки ntp владеют 1 точным временем, согласованием которого они постоянно занимаются

также как и TCP - две точки владеют одной очередью пакетов, согласованием которой они постоянно занимаются

>просто, две точки ntp владеют 1 точным временем

Нет точного времени. Не бывает. Есть договорённость о том, что мы считаем таковым.

>также как и TCP - две точки владеют одной очередью

Причём каждая своей. И "синхронизируют" свои представления о состоянии "peer"а меру своих возможностей поверх недетерминированого канала.

>может я что упустил, и в MPI полность решена проблема синхронизации?

И что там у вас за проблемы ? ;)

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

Пацтулом ;) Какого такого "сетевого взаимодействия" ?

Есть такая _абстракция_ как "коммуникатор", слышали когда нибудь про такой ?

>Ради развлечения попробуйте написать простую вещь - два паралельных блока кода которые исполнятся _одновременно_, или на худой конец с разницей не более чем n единиц времени, и докажите, что оно так и есть. Сокеты разрешается использовать :)

Это типа навтыкать

#pragma omp barrier для OpenMP

или

MPI::COMM_WORLD.Barrier() для MPI

Через строчку чтоли ;)

Ну очень полезное занятие ;)

PS: Странно, почему у меня задачи неделями крутятся на 40 процессорах сразу без всяких дедлоков (надо ради интереса поставить счётчик количества синхронизация) ведь написать многопоточное приложение оказывается невозможно ;)

Угу не так, например в Win, процесс - это абстракция "легкого" процесса, а thread - это нечто более "тяжелое". Вот именно поэтому все другие ОС сосут у Linux

>Угу не так, например в Win, процесс - это абстракция "легкого" процесса

Процессы в Win это способ группировки тредов, не более. По дефолту внутри процесса создается один тред, но потом он может сделать clone() который там называется CreateThread().