максимальный размер шмата shm

Размер шаред мемори в Sys V определяется параметром в функции shm_open(), в man shm_open сказано что она использует open(), и создаёт файл в /dev/shm, это файловая системе tmpfs, хорошее описание tmpfs на http://www.opennet.ru

Тебе надо почитать доку на tmpfs, там все ответы на все твои вопросы. Идея файловой системы tmpfs очень хорошая :)

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

>Размер шаред мемори в Sys V определяется параметром в функции shm_open(), в man shm_open сказано что она использует open(), и создаёт файл в /dev/shm, это файловая системе tmpfs, хорошее описание tmpfs на http://www.opennet.ru

>Тебе надо почитать доку на tmpfs, там все ответы на все твои вопросы. Идея файловой системы tmpfs очень хорошая :)

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

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

опасения человека вполне оправданы. но ничё полезного на вскидку не скажу

ССори, размер файла задаётсфя конечно же в mmap() ;)

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

Баг в книге Стивенса "UNIX взаимодействие процессов", по межпроцессному обмену: страница 239, глава 10, 10.1.Введение, Читаем всю страницу, но особенно внимательно читаем предложение: "Все три типа семафоров могут использоваться для синхронизации как отдельных процессов, так и потоков одного процесса.". К Линуксу это предложение не имеет АБСОЛЮТНО ни какго отношения, потому что ни кто не сможет засинхронизировать процессы посредством posix семафоров.

P.S. Стивенс полезен для общего понимания, как инциклопедия, но надо читать доку от разработчиков.

>К Линуксу это предложение не имеет АБСОЛЮТНО ни какго отношения, потому что ни кто не сможет засинхронизировать процессы посредством posix семафоров.

похоже что вы всю ночь не спали.

а на тему как засинхронизировать процессы посредством posix семафоров под линукс поройтесь в архиве сайта или прочитайте man posixoptions

С помощью posix семафоров синхронизируются потоки, а процессы не синхронизируются.

man posixoptions не содержит информации о засинхронизации процессов через posix семафоры.

>man posixoptions не содержит информации о засинхронизации процессов через posix семафоры.

а это что такое:

...
TSH - _POSIX_THREAD_PROCESS_SHARED - _SC_THREAD_PROCESS_SHARED
       Affected functions are
           pthread_mutexattr_getpshared(),
           pthread_mutexattr_setpshared()
...
???

> С помощью posix семафоров синхронизируются потоки, а процессы не синхронизируются.

по POSIX через самафоры синхронизуются и процессы и потоки. как named так и unnamed. реализовано ли это в конкретной ОС и как - уже другой вопрос.

// wbr

2cvv :

В Линухе до недавнего времени пост в posix семафор из одного процесса не будил спящий на нем другой процесс. Может, починили?

2anonymous (*) (19.09.2005 12:37:02):

Например,

echo 536870912 > /proc/sys/kernel/shmmax

> В Линухе до недавнего времени пост в posix семафор из одного процесса не будил спящий на нем другой процесс.

ессно семафор при этом размещается в разделяемой памяти, доступной обоим процессам? в своё время это была моя "любимая" ошибка.. :)

// wbr

anonymous (*) (19.09.2005 12:37:02):

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

Советую вместо SySV ipc воспользоваться mmap( .... MAP_SHARED|MAP_ANONYMOUS...) Описываемая проблема как раз ложиться на mmap.

klalafuda

> ессно семафор при этом размещается в разделяемой памяти, доступной обоим процессам?

Разумеется!

Проблема была в том, что для пробуждения в pthread юзались rt сигналы. Ессно, чужой процесс их не получал.

Правильно ли я вас понимаю, что для синхронизации процессов и нитей, в Линуксе, можно использовать posix мьютексы, а не posix семафоры: sem_wait(), sem_post()?

Die-Hard

Т.е. мьютексы теперь можно размещать в шаред мемори для синхронизации процессов?

> Т.е. мьютексы теперь можно размещать в шаред мемори для синхронизации процессов?

AFAIK нет, для синхронизации процессов годятся только семафоры.

// wbr

Еще раз:

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

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

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

Die-Hard

Вот тото и оно... Стандарт - одно, а реализации везде по разному. Где то я видел новость про интервью Линуса Торвальдса. Он говорил - "мы не собираемся делать POSIX совместимую ОС".

:(

>Правильно ли я вас понимаю, что для синхронизации процессов и нитей, в Линуксе, можно использовать posix мьютексы, а не posix семафоры: sem_wait(), sem_post()?

согласно posix должны работать и мьютексы и семафоры

если мне не изменяет память то под линуксом на текущий момент есть поддержка мьютексов. если надо определить присутствие этого в конкретном релизе то смотрим определён ли макрос из приведённого мною мана.

больше не нескажу ибо давно не вникал в тему.

Где то я видел новость про интервью Линуса Торвальдса. Он говорил - "мы не собираемся делать POSIX совместимую ОС".

на наше счастье pthread реализовывает RedHat ;-)

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

> согласно posix должны работать и мьютексы и семафоры

можно ссылку на POSIX где говорится, что mutex должны работать между процессами?

// wbr

По всей видимости POSIX это может не поддерживать, а реализация Линукса теоритически может (по ссылке cvv (*) (19.09.2005 14:53:41))

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

anonymous (*) (19.09.2005 15:59:15):

> Значит, насколько я поняла, mmap может захватывать сколько угодно оперативки?

Да. И даже больше :) (в пределах сегмента, разумеется).

И SySV тоже можно заставить это сделать (см. мой пост выше про /proc/sys/kernel/shmmax), правда, требуется root. Но с SySV на этом пути будут проблемы (как и со всеми SySV IPC) -- нужно быть _очень_ осторожным, иначе мгновенно все ресурсы будут выедены. Вообще, SySV -- не Unix-way.

s/Вообще, SySV -- не Unix-way/Вообще, SySV IPC -- не Unix-way/

Окей, поняла, а что тогда настоящий unix-way? :)

anonymous (*) (19.09.2005 16:25:49):

> а что тогда настоящий unix-way? :)

buf=(char *)mmap(0,thesize,PROT_READ|PROT_WRITE,MAP_SHARED|MAP_ANONYMOUS, 0, 0);

... fork() ...

Как все сдохнут, память вернется системе.

Не надо бояться overcommitment, MAP_SHARED обеспечит COW. Для вящего эстетизму можно после форка делать munmap на ненужные страницы (я обычно делаю :), но это, вообще говоря, лишнее.

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

>выходит, работа с объектом не такая как с обычным дескриптором?

10 отличий в студию!!!

>какой тогда дескриптор назначать?

в приведённом примере дескриптор игнорируется

а иначе только тот который вернула система

>(сорри, что юзаю вас, как ман... но не все женщины такие тупые, поверьте :))))

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

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

ну, мне тогда непривлекательность не грозит...:))))

О, попутно еще один вопрос всплыл: mmap, если не указывать адреса, не мжет использоваться другой группой процессов? ведь не наследуется же тогда отображенная в памяти переменная или файл?

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

mmap() в приведенном примере срабатывает _почти_ как malloc() (если бы был флаг MAP_PRIVATE, то был бы просто кусочек malloc()'а), но флаг MAP_SHARED приводит к тому, что вместо COW после форка выделенный кусок памяти будет виден одинаково и из дочки, и из папы.

После возврата из mmap() физическая память еще _не_ выделена; только при попытке что-то записать ядро разместит соответствующую страницу физической памяти, которая сразу будет доступна и из дочки, и из папы.

char *buf;

buf=(char *)mmap(0,1048576,PROT_READ|PROT_WRITE,MAP_SHARED|MAP_ANONYMOUS, 0, 0);

if(buf == MAP_FAILED) жужжим и помираем;

...

thepid=fork();

(тут все еще физической памяти не выделено)

...

if(thepid == 0) strcpy(buf+getpagesize(),"The child!");

(теперь одна страница памяти размещена и отображена по адресу buf+getpagesize(); причем на мультипроцессорной NUMA машине она размещена аффинно к дочке).

if(thepid != 0) strcpy(buf,"The father");

(теперь еше одна страница памяти размещена и отображена по адресу buf; причем на мультипроцессорной NUMA машине она размещена аффинно к папе. И из дочки, и из папы обращение типа printf("%s\n",buf) приведет к печати "The father", а printf("%s\n",buf+getpagesize()) -- "The child!").

> сорри, что юзаю вас, как ман... но не все женщины такие тупые, поверьте :)

Понятие тупизны может относится к анонимусам, но не к женшинам! (про женщину говорят "наивная").

:-)

Sorry, немного путано сказал Die-Hard 19.09.2005 16:52:14):

> MAP_SHARED обеспечит COW.

Конечно, речь не про COW (Copy-On-Write) после форка шла, а о том, что физические страницы памяти будут выделены только после обращения по соответствующему виртуальному адресу.

mmap в качестве средства создания разделяемой памяти подходит для родственных (связанных цепочкой форков) процессов.

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