LINUX.ORG.RU

Совместное использование ресурсов

 , ,


1

3

Есть проблема доступа к совместным ресурсам. Я вот не пойму, это реальная проблема, или она надумана?

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

Пусть есть условная ячейка памяти, которую разные процессы могут инкрементить. Как принято представлять эту модель? Процесс №1 считывает текущее значение из памяти(допустим - это 0), прибавляет к нему единицу, а затем записывает в память получившееся значение вместо предыдущего. Соответственно пока процесс №1 производит операцию сложения, процесс №2 может считать значение памяти, и начать свою операцию сложения. Затем, после того как процесс №1 записал результат(1) в память, процесс № 2 также записывает свой результат(1) в память, и результат 2-х инкрементов — 1.

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

Это все выглядит уродливо, как кровавое месиво.

Давайте посмотрим на это с другой стороны.

Есть условная ячейка, к которой имеет доступ только один процесс, который умеет ее инкрементить. Остальные процессы могут послать сообщения этому процессу, с «просьбой» инкрементации. При этом, эти мессенджеры абстрагированны от текущего значения счетчика, нет нужды считывать значения и производить собственные операции над этим значением, их дело — послать собщение и все. Они не имеют никакого доступа к этой памяти.

То есть, обычная инкапсуляция. И нет никакой проблемы.

Если это так просто, то зачем городить огород? Зачем решать несуществующие проблемы? Может это выгодно всякого рода горе-дезигнерам, делать вид, что существует проблема, нет проблемы — нет и хлебушка с маслицем?

Перемещено tailgunner из development

Перемещено jollheef из job

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

код метода выполняется в контексте вызывающего потока.

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

vikingfilmtracker
() автор топика
Ответ на: комментарий от Harald

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

Да уж...

rezedent12 ☆☆☆
()
Ответ на: комментарий от vikingfilmtracker

Ну вот я вызываю из другого контекста push(theMessage), как в этот момент заставить твой процесс бросить скажем обновление shared памяти и начать выполнять тело метода. Или мне придётся заблокироваться и подождать пока он не освободится и не заберёт у меня данные?

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

а два других хотят в нее писать

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

Аналог из жизни.

1-й случай. лежит лист бумаги и все желающие в нее пишут

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

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

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

Прекрасная аналогия. А что произойдёт, если два человека начнут диктовать? Диктующий должен заблокировать писаря и диктовать ему единолично.

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

как в этот момент заставить твой процесс бросить скажем обновление shared памяти и начать выполнять тело метода

В этом нет нужды. Этот процесс не должен прерываться. Внутри себя он исполняется синхронно

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

В моей модели нет такого понятия как «писать в» в обычном смысле

под «писать» я имел ввиду, что процессы просто хотят положить в твою очередь что-то.

давай остановимся на реализации конкретно «посылки сообщения». забудь ненадолго про свои акторы и попытайся объяснить на низком уровне, как происходит отправка сообщения одним процессом другому на уровне твоей системы

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

Наоборот, рисарь занятый записью одной диктовки не будет отвлекаться на другую, пока не закончит запись. Второй диктующий должен будет обратится позже. Реально, конфликта одновременного обращения не произойдет. И клиенты будут обслужены в порядке очереди. Но если даже такое и произойдет, можно просто недетерминированно выбрать одного из двух «подкидыванием монетки»

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

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

Да, она кривая и не совершенная. Хотя тут ты тоже не прав. В процессоре архитектуры X86_64 есть механизм защиты страниц памяти от исполнения или записи. И если бы операционные системы его бы использовали бы как полагается, то не было бы многих проблем с безопасностью.

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

rezedent12 ☆☆☆
()
Ответ на: комментарий от vikingfilmtracker

Просто на уровне железа не реализованы нормальные абстракции.

Чем больше абстракций в процессоре, тем больше транзисторов. А они все греются. Когда то кстати таким способом повышали производительность, используя принцип CISC. Но потом таки смогли повысить частоты и выяснилось что они упираются в опухшее от лишней логики ядро процессора. И выяснилось что подход RISC лучше. Тогда в X86 сделали ещё одну абстракцию, засунули RISC ядра в CISC обёртку, на этом кстати теряется 30% производительности, особенно в старом двоичном коде.

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

rezedent12 ☆☆☆
()
Ответ на: комментарий от vikingfilmtracker

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

Аналогии хороши, но они не схожи на 100%. Если человек может попытаться слушать только одного, то вот в железе такое не прокатит. Если транзистор откроется и пустит ток по шине, то его «перекричать» без риска что-нибудь сжечь не выйдет.

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

давай остановимся на реализации конкретно «посылки сообщения»

Посылку сообщений можно реализовать бесчисленным количесвом способов. Я не знаю, конкретного железа, но это самоочевидная вещь с точки зрения даже электроники. Посылка сообщения — это в простом случае сигнал, в котором что-либо закодированно, например определенной частотой вещания. Такие сообщения могут параллельно гулять по одной общей шине, и ограничены только физическим током, который может выдержать эта шина. Например, на таком принципе реализована технология DSL. Да и принципы теле/на том же самом принципе основаны. Даже коммуникация между людьми, и даже между животными. Не представляю, какие проблемы могут быть в реализации этой естественной модели

vikingfilmtracker
() автор топика
Ответ на: комментарий от ox55ff

Если транзистор откроется и пустит ток по шине, то его «перекричать» без риска что-нибудь сжечь не выйдет

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

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

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

Как он не будет отвлекаться?

Второй диктующий должен будет обратится позже.

Как бы тебе обяснить...

Представь, между процессами есть общая страница памяти 2^12 байт, то есть 4096 байт. Что бы было понятно прикладнику, представь её массивом

Public ShareMemory As Byte [4096]
У тебя есть просто общая память и никаких специальных функций процессора, функции ОС не используй тоже ибо они не совершенны и делаю то что тебе противно.

А теперь реши задачу. Есть 8 процессов которые работаю одновременно. Организуй надёжную блокировку первых 1024 элементов массива при помощи остальных элементов. Атомарными являются операции записи и чтения. Все логические и арифметические операции происходят не напрямую с ячейками, а исключительно внутри регистров процессора (RISC архитектура ARM). Операция изменения ячейки такова:
1) Чтение ячейки в регистр.
2) Изменение содержимого регистра.
3) Запись результата обратно в ячейку.
Минимум 3 такта. То есть ты должен учитывать что во время любого из этих действий другой процесс может тоже начать их делать.

rezedent12 ☆☆☆
()
Ответ на: комментарий от vikingfilmtracker

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

Внутри процессора нет никакой модуляции, только такты и логические уровни.

rezedent12 ☆☆☆
()
Ответ на: комментарий от vikingfilmtracker

Собираешься гонять по шинам аналоговый сигнал? Добавлять по обеим сторонам шины модулятор/демодулятор. На сколько это будет сложнее, дороже, медленнее? И всё это ты готов затеять, лишь бы не использовать блокировки?

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

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

Возможно это было бы более громоздко, но это не должно быть медленней, по-логике.

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

Я что-то сомневаюсь, что это было бы медленней

Частота процессорного ядра 3 гигагерца. Для частотного мультиплексирования сигналов 4 ядер в общую шину, нужна будет частота минимум 12 гигагерц (в реальности в несколько раз больше).

rezedent12 ☆☆☆
()
Ответ на: комментарий от ox55ff

А вообще ты толстый тролль. Ну не может человек быть настолько некомпетентным.

Может. Как сказал Эйнштейн бесконечны человеческая глупость и вселенная.

Deleted
()

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

Stil ★★★★★
()
Последнее исправление: Stil (всего исправлений: 1)
Ответ на: комментарий от vikingfilmtracker

ну, пусть будет другой процесс, который за этим следит, например

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

panzerito
()

Похоже пациент не из нашей области мегаверсума, у них там свои законы физики ))))) Но одно приятно - похоже антропный принцип всё же работает :)

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Это конечно уход от темы, но я бы, вообще говоря, усилил этот самый принцип, доведя до логичной стадии абсолютного релятивизма: наблюдатель и наблюдаемое(в тч вселенная) — составляют единство, и одно без другого невозможно в принципе. Ничего из этого не имеет самомтоятельного существования

vikingfilmtracker
() автор топика

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

Кажется что на любой платформе есть средства для выполнения атомарного инкремента. Ни блокировки, ни выделенный поток для этого не нужны.

ei-grad ★★★★★
()

Про то, зачем нужны блокировки при передаче сообщений - https://golang.org/src/runtime/chan.go#L177. Без блокировок тоже можно, но это не будет более эффективно.

ei-grad ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Похоже пациент не из нашей области мегаверсума, у них там свои законы физики ))))) Но одно приятно - похоже антропный принцип всё же работает :)

LSD изменяет скорость света и одновременность событий.

rezedent12 ☆☆☆
()
Ответ на: комментарий от ei-grad

Кажется что на любой платформе есть средства для выполнения атомарного инкремента. Ни блокировки, ни выделенный поток для этого не нужны.

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

rezedent12 ☆☆☆
()

С удовольствем прочитал тему. Покуда у меня один вопрос - почему тема всё ещё Development?

sand_circle
()

Это проблема архитектуры современных процессоров, если совсем грубо. Хотя программно инкапсуляцию сделать можно, как правило она очень и очень упрощённая и полноценную сделать не выйдет, потому что процессор один и ядро OS одно. Теоретически можно наворотить наноядро и кучу работающих процессов с разным уровнем доступа, но это будет едва ли эффективно. О чём это я? То о чём ты говоришь есть в живых организмах, каждая часть делает свою работу и обладает значительной независимостью, часто не только аналогом вычистительной мощи, но и автономным питанием, хранением данных и тд. То есть для нормальной инкапсуляции, честной так сказать, каждая программа должна иметь возможность хранить свои данные сама, сама себя рулить и тд. И такие программы должны быть выстроены в сеть. Это возможно, но программисты в большинстве своём так думать не умеют, людская инженерия вообще двигается в несколько ином направлении.

Ежели же попытаться делать один процесс посылает другому, вместо обычных блокировок, то будет оверхед, потому что в конечном счёте всё равно будут блокировки, но они просто скрыты под слоями api. Поэтому старые добрые механизмы межпроцессного и межпотокового взаимодействия самое что ни есть ТРУ на сегодня.

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

но это будет едва ли эффективно.

Нашел видео, интересное, как раз на эту тему, где 2 клоуна спорят с Карлом Хьюиттом. Там, где то в середине видео, как раз, непосредственно про эффективность блокировки и тд. Касаются также и дизайна симулы, псевдоконкурентность и тп.

Я, правда, мало что понимаю:) Если есть желание, и тема интересна, зацени:

https://channel9.msdn.com/Blogs/Charles/A-Conversation-with-Bjarne-Stroustrup...

vikingfilmtracker
() автор топика
Ответ на: комментарий от ixrws

Я к тому, что Карл Хьюитт не согласен с тем, что это должно быть неэффективно, он утверждает обратное.

vikingfilmtracker
() автор топика
Ответ на: комментарий от rezedent12

Блокировка страниц памяти есть на многих процессорах поддерживающих виртуальную память

Это не те блокировки о которых идёт речь в треде. Виртуальная память и странички не имеют никакого отношения к примитивам синхронизации.

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

Это не те блокировки о которых идёт речь в треде. Виртуальная память и странички не имеют никакого отношения к примитивам синхронизации.

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

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

процесс пытаясь записать данные на заблокированную страницу будет останавливаться

Это странное что-то, скорее всего ты это придумал сам)

Ты не про mlock случайно? Он про другое совсем, про то чтобы страница в swap не уходила.

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

процесс пытаясь записать данные на заблокированную страницу будет останавливаться

Это странное что-то, скорее всего ты это придумал сам)

Нет, такой подход в самом деле существует. Было время, когда так делали distributed shared memory.

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

А кто и как её будет блокировать? Собственно у тебя только часть связанная с ожиданием ресурса, а не с самой блокировкой.

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

Тс забыл о кешах. L1, L3, память - это не просто память, она многоступенчата. Плюс «слать сообщения» - это значит ещё одну сущность создавать, которая будет узким горлышком и будет работать в той же системе памяти с вытекающим гемором.

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

Зарегистрировался ради тебя. Раз тебе так никто помочь так и не смог.

Нет там никакой принципиальной проблемы, это совершенно очевидно.

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

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

Т.е. здесь твои асинхронные задачи могут существовать только как части другой задачи. И естественно части какой-то задачи не могут бы не синхронны.

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

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

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

Если же мы доходим до очереди в кассу, то опять же та же самая проблема - очередь одна, а путей к ней много. И у людей возникает так же проблема. Как всё это соединить в один поток? Какая здесь проблема?

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

И в магазине так же - если я с васей одновременно пойду вставать за петей - мы уткнёмся лбами друг в друга. Финиш.

все разрешается естественным образом.

Что значит естественным? Решается точно так же способом. Во-первых все покупатели в магазине синхронизированы. Именно поэтому это и решается. Во-вторых решается это точно так же - кто-то кого-то пропускает вперёд.

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

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

Теперь уже конкретно разберём следствие этих ошибок в твоих постах.

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

Развитие основной «идеи» отсюда:

Есть условная ячейка, к которой имеет доступ только один процесс, который умеет ее инкрементить. Остальные процессы могут послать сообщения этому процессу, с «просьбой» инкрементации. При этом, эти мессенджеры абстрагированны от текущего значения счетчика, нет нужды считывать значения и производить собственные операции над этим значением, их дело — послать собщение и все. Они не имеют никакого доступа к этой памяти.

Из этого следует то, что в конечном итоге нам нужен список просьб. Что такое список? Это последовательная запись чего-то, что и будет нашей просьбой. Что нам нужно знать для того, чтобы запись что-то в список? Правильно - последнюю запись.

Если у нас асинхронные запросы на добавление просьб, то и сам список просьб должен быть независимым, что не является действительностью, ибо список у нас синхронный, ибо в конечном итоге он у нас один. Исполнение просьб так же синхронно, ибо исполнитель у нас один. Да и запись самой просьбы является ничем иным как частичным её исполнением.

Из всего это следует то, что невозможно сделать асинхронную очередь. Никак. И что ты не делай - ты не получишь асинхронности. Ты уже нарушил её правило.

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

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

В данном случае на примере попроще вышло так. Есть барабан, который крутят Петя, Вася и Федот. Мы хотим крутить асинхронно. Ты придумал что? Добавить Алёшу, которому они будут говорить «крути» - т.е. просьбу. Казалось бы сказать сказать можно и тогда, когда барабан крутят. И мы решили проблему.

На самом деле нет. Ведь пока Вася просит Алёшу, то Петя просить у Алёши не может. И ситуация повторилась, только уже вместо барабана выступает Алёша. А вместо действия «крутить» выступает действие «сказать просьбу».

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

Чем больше абстракций в процессоре, тем больше транзисторов. А они все греются.

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

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

Когда то кстати таким способом повышали производительность, используя принцип CISC.

Спорное заявление. Действительно - это может иметь смысл. Если у нас топорный пайплайн с максимальной единицей исполнения «инструкция», то чем сложнее инструкция - тем в конечном итоге больше мы можем получить.

Но потом таки смогли повысить частоты и выяснилось что они упираются в опухшее от лишней логики ядро процессора.

В веб бума техпроцесса? Сомневаюсь.

И выяснилось что подход RISC лучше.

Выяснилось не это. Выяснилось то, что риск не масштабируемый. Хотя что тут выяснять - это ясно любому школьнику. Ибо любой пайплайн, а в будущем и суперскалярность есть ни что иное как параллелизм. Хотя конечно - декодирование, а вернее резка на чанки есть малая часть работы ядра, но закон Амдала никто не отменял.

Тогда в X86 сделали ещё одну абстракцию, засунули RISC ядра в CISC обёртку, на этом кстати теряется 30% производительности, особенно в старом двоичном коде.

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

На этом х86 ничего не теряет. Он просто не может развиваться дальше в уровень параллелизма на уровне инструкций. Его бекенд уже давно быстрее фронтенда. Но только тут уже возникает проблема иная - это никому не надо, ибо задействовать этот параллелизм мало кто может. Да даже текущий мало кто может.

Сложно назвать плюсы, которые даст х86 новая архитектура.

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

Увидел ник в трекере, предположил анонiмуса, не ошибся!

Т.е. ты меня назвал анонiмусом? Анонiмус это ТС, либо я то же анонiмус?

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

Увидел ник в трекере, предположил анонiмуса, не ошибся!

Персонаж, которому ты ответил - скорее всего Царь.

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

Точняк, обознался. Привык, что он опознаётся по незнакомому нику и простыням текста.

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

Ишь ты какой шустрый, с провода вообще не слезаешь уже?

Не ВРИ экстрасенс, слишком грамотная и сдержанная речь для царя. Не царский это стиль.

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

слишком грамотная и сдержанная речь для царя. Не царский это стиль.

Царь не всегда говорит так, как говорил на ЛОР - на Хабре он был гораздо сдержаннее. Но набор слов характерный для царя, и, если это он, он скоро сорвется.

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

Это странное что-то, скорее всего ты это придумал сам)

https://ru.wikipedia.org/wiki/Страничная_память

  • поддержка изоляции процессов и защиты памяти путём создания своего собственного виртуального адресного пространства для каждого процесса
  • поддержка изоляции области ядра от кода пользовательского режима
  • поддержка памяти «только для чтения» и неисполняемой памяти
  • поддержка отгрузки давно не используемых страниц в область подкачки на диске (см. свопинг)
  • поддержка отображённых в память файлов, в том числе загрузочных модулей
  • поддержка разделяемой между процессами памяти, в том числе с копированием-по-записи для экономии физических страниц
  • поддержка системного вызова fork() в ОС семейства UNIX
rezedent12 ☆☆☆
()
Ответ на: комментарий от mashina

А кто и как её будет блокировать? Собственно у тебя только часть связанная с ожиданием ресурса, а не с самой блокировкой.

Очень просто:
1) Каждый процесс которому нужно взять буфер, пишет свой ID в специальную страницу.
2) На страницу поставлен флаг «только чтение». Поэтому происходит исключение (ошибка) обрабатываемое диспетчером памяти.
3) Процесс вызвавший исключение останавливается, а то что он пытался записать, считывается обработчиком. Таким образом у нас есть ID процесса который хочет занять буфер и этот процесс остановлен.
4) Пишем в пямять этого процесса ответ на запрос, например «буфер твой». И возобновляем выполнение процесса.
5) Когда процессу буфер больше не нужен, он пишет во флаговую страницу «буфер освобождаю». Это вызывает опять прерывание и тем самым посылает сигнал диспетчеру буфера о том что нужно обработать следующий в очереди процесс.

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

rezedent12 ☆☆☆
()
Ответ на: комментарий от mtiexpert

Ошибка в его рассуждениях заключается в том что он считает атомарными, многие из тех процессов и действий который атомарными не являются. Ибо для него они инкапсулированы в «магическое заклинание».

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