Брюс Эккель признался в бессилии

>мы по разному понимаем слово "принадлежит" ... я - возможность оперирования над

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

Однако "однопоточные" программы могут себе позволить себе _иллюзию_ "возможности оперировать", причём только потому, что второго желающего нет, или его "прячет" операционка. Многопоточные же должны учитывать этот факт(*), потому не избавленые этой иллюзии программисты пишут глюкавые программы, а избавленые говорят, "я, вероятно, никогда не напишу правильно".

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

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

>Absurd (*) (18.09.2007 14:51:39)

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

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

Бред, еще раз говорю смотрите вызов clone()

>еще раз говорю смотрите вызов clone()

Поясните тёмному, какая может быть связь между реализацией вызова clone и возможностью процессора откладывать операции или переключать контексты когда это ему взбредёт в регистры?

>> просто, две точки ntp владеют 1 точным временем
> Нет точного времени. Не бывает. Есть договорённость о том, что мы считаем таковым.

это уже вопрос определения

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

то-же самое но другими словами

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

посмотрел на MPI 2.0 - понравилось :)
только речь то все равно не о MPI :)

>> человечище, обсуждается проблемы конкурентного программирования, а не сетевого взаимодействия.
> Пацтулом ;) Какого такого "сетевого взаимодействия" ?
> Есть такая _абстракция_ как "коммуникатор", слышали когда нибудь про такой ?

если бы почитали повнимательнее то заметили, что сокеты приводились как пример stateless синхронизации .....

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

> Это типа навтыкать
> #pragma omp barrier для OpenMP
> или
> MPI::COMM_WORLD.Barrier() для MPI
> Через строчку чтоли ;)
> Ну очень полезное занятие ;)

даже это не гарантирует одновременности, ведь так ? :)
покрайней мере доказать вы это принципиально никогда не сможете :)))))

>> мы по разному понимаем слово "принадлежит" ... я - возможность оперирования над

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

Однако "однопоточные" программы могут себе позволить себе _иллюзию_ "возможности оперировать", причём только потому, что второго желающего нет, или его "прячет" операционка. Многопоточные же должны учитывать этот факт(*), потому не избавленые этой иллюзии программисты пишут глюкавые программы, а избавленые говорят, "я, вероятно, никогда не напишу правильно".

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

DonkeyHot Вы сейчас очень убедительно доказали что Ахилесс никогда не догонит черепаху. Я уже говорил мы указываем на разные вещи - __Вы на необходимость эксклюзивного доступа__, я на __необходимость доступа вообще__. Как вы обеспечите эксклюзивный доступ, если у вас его __вообще__ нет ?

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

Магия, да ? :) Я и сам удивляюсь.
Шутка задачки о одновременности заключается в том, что одновременность нельзя проверить, так как фиксация интервала так-же занимает время :)

Правильно многопоточное приложение можно написать, только сложность заключается и в том, на что указал DonkeyHot - даже понятие "принадлежит" становиться несколько "объемным"

>Шутка задачки о одновременности заключается в том, что одновременность нельзя проверить, так как фиксация интервала так-же занимает время :)

Демагогия да и только.

>даже это не гарантирует одновременности, ведь так ? :) >покрайней мере доказать вы это принципиально никогда не сможете :)))))

А, понятно - вы про сферических коней в не менее сферическом вакууме ?

Релятивистские эффекты разного течения времени в двух разных точка пространства да ? ;)

>посмотрел на MPI 2.0 - понравилось :)

А сейчас попробуйте а не гоняйте больше ваших коней в вакууме.

> Демагогия да и только.

если бы все так просто - сказал:"фигня", и нет проблем :)

> А, понятно - вы про сферических коней в не менее сферическом вакууме
> Релятивистские эффекты разного течения времени в двух разных точка пространства да ? ;)

нет, а про то, что многопоточная программа - достаточно интересный мат объект :), с интересным свойством - наличием времени :)
Вы, наверное, несколько, недопонимаете. Наверное вы думаете, что если собрать одинаковые задачи на барьере то можно со 100% вероятностью утверждать, что следующая инструкция (за барьером) каждой выполниться одновременно. Давайте я вас обломаю - __никогда__ такого не будет.
Даже если барьер - квантовое устройство и то - вероятность.

> А сейчас попробуйте а не гоняйте больше ваших коней в вакууме.

зачем ? ради сферической убежденности, в сферичности вакуума? я не занимаюсь вычислениями

Да иптыть, и где таких занудных троллей делают?

Пипл, завязывайте его кормить, а то весь топик засрёт.

нечитай

>Вы сейчас очень убедительно доказали

Получилось :)

>Вы на необходимость эксклюзивного

Неверно. Я указывал на простоту разработки, связаную с достоверностью иллюзии эксклюзивного доступа.

>я на __необходимость доступа вообще__.

не вообще, а

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

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

> Наверное вы думаете, что если собрать одинаковые задачи на барьере то можно со 100% вероятностью утверждать, что следующая инструкция (за барьером) каждой выполниться одновременно.

С каких коврижек ? Вы видимо не понимаете с какой целью применяются барьеры. Никто это сделать и не пытается. Важна не мифическая "одновременность" а _порядок_ исполнения _блоков_ кода.

>я не занимаюсь вычислениями

Оно и заметно.

PS: Изначально речь шла о невозможности (с вашей точки зрения) синхронизации без общей (разделяемой) памяти. Какого вас занесло в какую то непонятную "одновременность" ?

я так понимаю это троллизм 4-й стадии ? ;)))

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

> Очевидно, последнее неверно, т.к. этот доступ не _должен_ быть синхронен. Более того, обеспечение _отсутствия_ этого составляет задачу синхронизации потоков.

1 для немых, запятая в русском языке указывает на синоним
2 доступ не может быть синхронным, синхронным может быть состояние
3 соленое чевидно не равно красному

> И решается она в т.ч. железом, обеспечивающим не-синхронность состояния обьекта для разных потоков "выполнения".

я фигею дорогая редакция - железо обеспечивает невозможность узнать из разных потоков, заблокирован ли мютекс

>> Вы сейчас очень убедительно доказали
> Получилось :)

Вы радуететесь что доказали парадокс Зенона ? мда - разговаривать с вами бессмысленно

>> Наверное вы думаете, что если собрать одинаковые задачи на барьере то можно со 100% вероятностью утверждать, что следующая инструкция (за барьером) каждой выполниться одновременно.

> С каких коврижек ?

думайте - это иногда полезно

> Вы видимо не понимаете с какой целью применяются барьеры. Никто это сделать и не пытается.

Разумеется не пытается. Зачем делать невозможное ?

> Важна не мифическая "одновременность" а _порядок_ исполнения _блоков_ кода.

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

>> я не занимаюсь вычислениями
> Оно и заметно.

Вам нимб голову не жмет? Яйца ходить не мешают?

> PS: Изначально речь шла о невозможности (с вашей точки зрения) синхронизации без общей (разделяемой) памяти. Какого вас занесло в какую то непонятную "одновременность" ?
я так понимаю это троллизм 4-й стадии ? ;)))

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

> я так понимаю это троллизм 4-й стадии ? ;)))

нет, это время потраченное впустую на людей не умеющих думать

> это время потраченное впустую на людей не умеющих думать

Не сдавайся, жги дальше!

зачем ?

я второй день пытаюсь объяснить, что:
несуществующее - не существует,
то что нельзя увидеть - невидимо,
если два потока не могут видеть что мютекс взведен, то они не могут синхронизоваться,
если не известно дошло ли сообщение, то неизвестно что получил адресат

>для немых, запятая в русском языке указывает на синоним

И с каких пор "немых" и "запятая" - синонимы? :)

>железо обеспечивает невозможность узнать из разных потоков, заблокирован ли мютекс

Именно. Железо обеспечивает видимость _разных_ состояний оного для разных потоков, буде они _одновременно_ захотят его "заблокировать". Ну, или невозможность одновременности. Так о какой "принадлежности обоим" ты говоришь?

ё-моё

> Именно. Железо обеспечивает видимость _разных_ состояний оного для разных потоков, буде они _одновременно_ захотят его "заблокировать". Ну, или невозможность одновременности. Так о какой "принадлежности обоим" ты говоришь?

мютекс заблокирован для всех потоков, имееет одно и то-же состояние - "заблокирован", для все потоков, видим во всех потоках, и предоставляет возможность проверить, заблокирован ли он, изо всех потоков.

мютекс и представляет собой тот shared entity (memory, раз имеет состояние) о котором и шла речь.


> И с каких пор "немых" и "запятая" - синонимы? :

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

> я второй день пытаюсь объяснить, что

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

> Ты второй день пытаешься объяснить очевидные вещи,

почему-бы просто согласиться с очевидными вещами?

> используя тяжеловесную наукообразную терминологию

болею я :)

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

1 не противоречит
2 какой такой новый смысл у shared entity ? shared она и на лоре shared
3 почитайте учебник, что-ли :)

тяжело, объяснить необходимость shared entity для синхронизации, особенно если человек не шарит
я начал с __абсолютно__ очевидного - системам нужно хоть как-то пересечься для взаимодействия ...

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

Куда можно подъезжать ? Следаю быстро и профессиАнально :)))