LINUX.ORG.RU

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

 , ,


1

3

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

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

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

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

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

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

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

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

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

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

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

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

«Мыши, станьте ёжиками.»

btw твоё решение будет более ресурсоёмкое, чем решения горе-дезигнеров.

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

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

mashina ★★★★★ ()

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

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

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

rezedent12 ☆☆☆ ()

Анонiмус, будь мужиком ― запили POC.

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

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

так ведь сообщение то получает процесс, а не ячейки памяти. Просто к этим ячейкам имеет доступ только один единственный процесс

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

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

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

так ведь сообщение то получает процесс, а не ячейки памяти. Просто к этим ячейкам имеет доступ только один единственный процесс

А сообщение этому единственному процессу как будет доставляться, через либастрал или таки через ячейки памяти?

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

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

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

но это другие ячейки памяти.

их тоже придётся блокировать

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

а факт окончания записи как будет сообщаться?

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

Но почему в вебе нет этих проблем? Почему не возникает проблемы совместного доступа к ресурсу(сайту)?

Потому что этим проблемы решены на низком уровне, критикуемым в первом сообщении способом.

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

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

Если ты посылаешь сообщение, то есть 2 подхода:
1) Все процессы пишут его в общий буфер (область памяти). Скорость высока, но и накладки возможны.
2) У каждого процесса свой буфер (область памяти), в котором он оставляет сообщение. А процесс-диспетчер по очереди проверяет буфер каждого клиента. Это медленно.

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

их тоже придётся блокировать

зачем? Ведь при совместном доступе блокировка нужна только от изменений(перезаписей) из-вне, у нас же нет никаких перезаписей из-вне

а факт окончания записи как будет сообщаться?

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

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

Просто к этим ячейкам имеет доступ только один единственный процесс

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

mashina ★★★★★ ()

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

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

зачем? Ведь при совместном доступе блокировка нужна только от изменений(перезаписей) из-вне, у нас же нет никаких перезаписей из-вне

А если 2 процесса будут писать сообщение одновременно? Какая каша получиться по твоему?

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

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

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

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

у нас же нет никаких перезаписей из-вне

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

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

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

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

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

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

Ахахвхахаха. Ахахвхахаха. Ухахахха.

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

Это в теории. А теперь расскажи каким образом они реализуются на практике в дискретных ЭВМ.

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

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

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

А если 2 процесса будут писать сообщение одновременно? Какая каша получиться по твоему?

Ну, порядок записей должен синхронизироваться естественно. Асинхронность не означает отсутствия возможностей синхронизации

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

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

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

Ну, порядок записей должен синхронизироваться естественно. Асинхронность не означает отсутствия возможностей синхронизации

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

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

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

А теперь вопрос. Как происходит блокировка в реальном исполнении?

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

А если 2 процесса будут писать сообщение одновременно? Какая каша получиться по твоему?

Ну, порядок записей должен синхронизироваться естественно. Асинхронность не означает отсутствия возможностей синхронизации

Перепутал, вот вопрос Совместное использование ресурсов (комментарий)

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

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

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

То есть, архитектура самого железа, значит, кривая.

Поэтому пытаются родить транзакционную память.

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

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

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

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

То есть, внешние процессы пушат в очередь сообщения, а она сама себя инкрементирует, как оно и происходит с обычным массивом, например

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

а очередь ведь тоже можно представлять как процесс, инкапсулирующий данные действия

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

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

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

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

Поэтому пытаются родить транзакционную память.

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

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

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

хорошо, давай начнем издалека. какой интерфейс будут использовать процессы, чтобы записать что-то в эту очередь?

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

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

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

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

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

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

Я не знаю, что ты в данном случае подразумеваешь под интерфейсом, но концептуально очередь должна быть актором, который принимает сообщения push(theMessage), и при каждом таком пуше, пишет сообщение в свою внутреннюю память и инкрементит счетчик. при этом, она может принимать сообщения тира pop только от потребителя(реципиента) этих сообщений. Сама по себе память инкапсулирована от внешних процессов, и является элементом реализакии актора «очередь» Вот такая, примерно, модель

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

который единолично пишет в память.

он пишет в свою внутреннюю память, к которой кроме него ни у кого доступа нет. Зачем его блокировать?

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

он пишет в свою внутреннюю память, к которой кроме него ни у кого доступа нет. Зачем его блокировать?

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

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

Я не знаю, что ты в данном случае подразумеваешь под интерфейсом, но концептуально

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

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

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