LINUX.ORG.RU

COW внутри процесса


0

0

Никто не подскажет, как сделать такое:

Мне надо сдублировать область памяти, но так, чтобы реальное копирование происходило только при записи во вторую копию, типа COW в MAP_PRIVATE регион после форка, но внутри моего единственного процесса (ок, допустимы POSIX threads).

То есть, например, у меня есть массив в char a[128]; я хочу его содержимое скопировать в массив b[128], но так, чтобы x=b[2] читалось с той страницы, на которую отображался массив a, если в массив b записи еще не было, а при записи, например, b[3]='!'; соотверствующая страница бы реально скопировалась.

★★★★★

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

> mprotect() с PROT_WRITE

Как?

Смартпоинтеры не предлагать :)

Die-Hard ★★★★★
() автор топика

> То есть, например, у меня есть массив в char a[128];

пусть этот массив живет в файле, доступ к нему mmap(MAP_SHARED).

причем у нас есть хорошие fs для этого: tmpfs, ramfs; так что
потерь по производительности не будет (хотя они и так были бы
небольшими, даже если это был бы файл в ext2, скажем).

> я хочу его содержимое скопировать в массив b[128], но так,
> чтобы x=b[2] читалось с той страницы, на которую отображался
> массив a, если в массив b записи еще не было, а при записи,
> например, b[3]='!'; соотверствующая страница бы реально
> скопировалась.

mmap(MAP_PRIVATE) того же файла и по тому же offset.

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

2idle

Да, я думал а этом направлении...

Меня все же смущает возможные проблемы с производительностью. Дело в том, что эта штука нужна не только под Линухом; мало того, fs может оказаться вообще сетевой...

А больше никак?

Die-Hard ★★★★★
() автор топика
Ответ на: комментарий от Die-Hard

> А больше никак?

мне ничего другого в голову не приходит....

> fs может оказаться вообще сетевой...

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

> Меня все же смущает возможные проблемы с производительностью.

да не должно быть никаких потерь (кроме собственно стоимости
mmap). запись этих страниц в файл будет происходить _только_
при нехватке памяти, т.е. как бы swapping. ну и после unmap,
конечно, если файл не был truncated/deleted. (это все про
MAP_SHARED, конечно).

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

idle:

> да не должно быть никаких потерь (кроме собственно стоимости mmap)

Мне кажется, mmap в _реальный_ файл (а для иcпользования MAP_PRIVATE мне нужен будет именно реальный файл!) должно быть достаточно накладным: надо убедиться в том, что файл существует, что права доступа соответствуют, посмотреть на кэши, etc.

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

Die-Hard ★★★★★
() автор топика
Ответ на: комментарий от Die-Hard

> Мне кажется, mmap в _реальный_ файл (а для иcпользования MAP_PRIVATE мне нужен будет именно реальный файл!)
> должно быть достаточно накладным:

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

но по-другому я не вижу как это сделать.

shm_open() не поможет. точнее, это то же самое через tmpfs.
как я уже говорил, особой разницы нет, записи в файл не будет
если не возникает нехватка памяти.

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

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

idle:

> ...это все нужно мерить,...

Да, ты прав, конечно.

Попробую на досуге бенчмарки погонять.

Thanks for discussion!

Die-Hard ★★★★★
() автор топика
Ответ на: комментарий от Die-Hard

>> а может тебе shm_open() поможет???

>Как?

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

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

2cvv :

А, блин!

Я не заметил подтира, и подумал почему-то про shmget.

Ну, это -- тот за самый open, только сбоку.

Хотя, пожалуй, портабильнее должен быть (в смысле изолированности от типа файловой системы).

С другой стороны, оно только в 2.4 Линуксе появилось...

Die-Hard ★★★★★
() автор топика
Ответ на: комментарий от Die-Hard

>Ну, это -- тот за самый open, только сбоку.

на линуксе. на других системах может быть что хочеш. Posix на эту тему ничего не требует

>Хотя, пожалуй, портабильнее должен быть (в смысле изолированности от типа файловой системы).

я собственно об этом и подумал

>С другой стороны, оно только в 2.4 Линуксе появилось...

я думаю что встретить более старый довольно проблематично

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

cvv:

>>С другой стороны, оно только в 2.4 Линуксе появилось...

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

У меня дома (в России) 2.0 стоит :)

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