use of 'shared memory' - comp.unix.programmer

Hi Roman, > Where (purposes, examples...) can be useful application of 'shared memory', > in case with shmget()/shmat() etc. ? shared memory is used for instance: (*) as fast inter-process communication (actually, one of the fastest) (*) in some applications where several processes share the same data. Some links: http://kt.squeakydolphin.com/sysv_shared_mem.jsp http://uregina.ca/~douglatr/ENSE%20473/Labs/tutorial3/ense_473_tut3.htm http://users.actcom.co.il/~choo/lupg/tutorials/multi-process/multi-process.html Cheers, Loic.

On 21/02/2006, Roman Mashak wrote: > Where (purposes, examples...) can be useful application of 'shared > memory', in case with shmget()/shmat() etc. ? POSIX.4 Programmers Guide : Programming for the Real World by Bill Gallmeister ISBN: 1565920740 has some interesting examples and discussions on shared memory and the issues surrounding its use, and some good advice on portability. I've tended to use the posix shared memory API (shm_open() etc) rather than shmget() etc. shm_open() allows multiple unrelated processes to easily access the same shared memory. -- Simon Elliott http://www.ctsn.co.uk

Simon Elliott wrote: > I've tended to use the posix shared memory API (shm_open() etc) rather > than shmget() etc. shm_open() allows multiple unrelated processes to > easily access the same shared memory. You can also have multiple unrelated processes mmap() a regular file in the filesystem and get the same effect. Chris

Roman Mashak wrote: > Where (purposes, examples...) can be useful application of 'shared memory', > in case with shmget()/shmat() etc. ? Run "ipcs" on your Linux (or probably other Unix-like) box as root and see what you're already using shared memory for. On my box, Postgresql uses it, X uses it, and CORBA apps (I think) use it. --Phil.

Hello, loic-dev@gmx.net! You wrote on 21 Feb 2006 05:11:03 -0800: ??>> Where (purposes, examples...) can be useful application of 'shared ??>> memory', in case with shmget()/shmat() etc. ? ld> shared memory is used for instance: ld> (*) as fast inter-process communication (actually, one of the fastest) ld> (*) in some applications where several processes share the same data. ld> Some links: ld> http://kt.squeakydolphin.com/sysv_shared_mem.jsp ld> http://uregina.ca/~douglatr/ENSE%20473/Labs/tutorial3/ense_473_tut3.htm ld> http://users.actcom.co.il/~choo/lupg/tutorials/multi-process/multi-proc ld> ess.html Thank you guys for links, researching now. I was wondering about shared memory usage, because thought it may be applied in my small network project: multiple clients connect to server via TCP protocol, and sometimes they need to make changes in file on server. It's presently based on 'fork()' model, pretty simple, but works fine so far, overhead is not heavy. Sometimes clients need to make changes in the file on server, and every client opens/writes/closes that file. So I assumed may be it's reasonable to keep it always opened in shared area and let them modify file according to needs, semaphores will watch concurrency issues. What do you think about it? With best regards, Roman Mashak. E-mail: mrv@tusur.ru

"Roman Mashak" <mrv@tusur.ru> writes: > Hello, loic-dev@gmx.net! > You wrote on 21 Feb 2006 05:11:03 -0800: > > ??>> Where (purposes, examples...) can be useful application of 'shared > ??>> memory', in case with shmget()/shmat() etc. ? > > ld> shared memory is used for instance: > ld> (*) as fast inter-process communication (actually, one of the fastest) > ld> (*) in some applications where several processes share the same data. > > ld> Some links: > ld> http://kt.squeakydolphin.com/sysv_shared_mem.jsp > ld> http://uregina.ca/~douglatr/ENSE%20473/Labs/tutorial3/ense_473_tut3.htm > ld> http://users.actcom.co.il/~choo/lupg/tutorials/multi-process/multi-proc > ld> ess.html > > Thank you guys for links, researching now. > I was wondering about shared memory usage, because thought it may be applied > in my small network project: multiple clients connect to server via TCP > protocol, and sometimes they need to make changes in file on server. It's > presently based on 'fork()' model, pretty simple, but works fine so far, > overhead is not heavy. Sometimes clients need to make changes in the file on > server, and every client opens/writes/closes that file. So I assumed may be > it's reasonable to keep it always opened in shared area and let them modify > file according to needs, semaphores will watch concurrency issues. > > What do you think about it? I think that networks are still much slower than hard disks. Well if you have a good 1Gb/s network card, on a a PCI-X bus, perhaps not. But with normal hardware, and if you go thru the Internet, not thru a LAN, what you need to optimize is not the hard disk. Moreover, the OS is already optimizing and caching all disk accessess for you: when you keep openining, reading or writing and closing the same file, everything is done in RAM. So you'd only swap and open and a close for a couple of semop syscalls: it won't make a difference. On the other hand, even with a file you may need to synchronize accesses... -- __Pascal Bourguignon__ http://www.informatimago.com/ There is no worse tyranny than to force a man to pay for what he does not want merely because you think it would be good for him. -- Robert Heinlein

Hello, Pascal! You wrote on Wed, 22 Feb 2006 06:20:45 +0100: [skip] PB> But with normal hardware, and if you go thru the Internet, not thru a PB> LAN, what you need to optimize is not the hard disk. That's what I wanted to know, I suspected I was moving in the wrong direction :-) PB> Moreover, the OS is already optimizing and caching all disk accessess PB> for you: when you keep openining, reading or writing and closing the Is it true for Linux with 2.4.x kernels as well? PB> same file, everything is done in RAM. So you'd only swap and open and PB> a close for a couple of semop syscalls: it won't make a difference. PB> On the other hand, even with a file you may need to synchronize PB> accesses... So, I'm planning to use semaphores. I think this is the only way? With best regards, Roman Mashak. E-mail: mrv@tusur.ru

Hi Roman, > [skip] > PB> But with normal hardware, and if you go thru the Internet, not thru a > PB> LAN, what you need to optimize is not the hard disk. > That's what I wanted to know, I suspected I was moving in the wrong > direction :-) Well, as quoted from Knuth/Hoare "Premature optimization is the root of all evil"... It is best to first have a simple design that works. And then, only if performances requires it, eliminate the most important bootleneck after profiling the code. > PB> Moreover, the OS is already optimizing and caching all disk accessess > PB> for you: when you keep openining, reading or writing and closing the > Is it true for Linux with 2.4.x kernels as well? Yes. Perhaps 2.6 does it better, but 2.4 has also optimization/cache for disk accesses. > PB> same file, everything is done in RAM. So you'd only swap and open and > PB> a close for a couple of semop syscalls: it won't make a difference. > > PB> On the other hand, even with a file you may need to synchronize > PB> accesses... > So, I'm planning to use semaphores. I think this is the only way? No. Another possibility would perhaps be file locks. See e.g.: http://www.gnu.org/software/libc/manual/html_node/File-Locks.html HTH, Loic.

loic-dev@gmx.net wrote: > Hi Roman, > > > [skip] > > PB> But with normal hardware, and if you go thru the Internet, not thru a > > PB> LAN, what you need to optimize is not the hard disk. > > That's what I wanted to know, I suspected I was moving in the wrong > > direction :-) > > Well, as quoted from Knuth/Hoare "Premature optimization is the root of > all evil"... > > It is best to first have a simple design that works. And then, only if > performances requires it, eliminate the most important bootleneck after > profiling the code. Can you tell me what does "profiling the code" mean? > > > PB> Moreover, the OS is already optimizing and caching all disk accessess > > PB> for you: when you keep openining, reading or writing and closing the > > Is it true for Linux with 2.4.x kernels as well? > > Yes. Perhaps 2.6 does it better, but 2.4 has also optimization/cache > for disk accesses. > > > PB> same file, everything is done in RAM. So you'd only swap and open and > > PB> a close for a couple of semop syscalls: it won't make a difference. > > > > PB> On the other hand, even with a file you may need to synchronize > > PB> accesses... > > So, I'm planning to use semaphores. I think this is the only way? > > No. Another possibility would perhaps be file locks. See e.g.: > http://www.gnu.org/software/libc/manual/html_node/File-Locks.html > > > HTH, > Loic.

Hello Sunil, > > It is best to first have a simple design that works. And then, only if > > performances requires it, eliminate the most important bootleneck after > > profiling the code. > > Can you tell me what does "profiling the code" mean? Code profiling is the action of measuring how much time is spend in what routine (this is usually achieved by using a software called profiler). That way, you know exactly where the bootlenecks are. Remember that roughly speaking the Paretto's rule apply: about 80% of the bootlenecks are generated by 20% of the code. The profiler helps you to find out where those 20% are... ( As a matter of fact, programmers are notorious for making bad assumptions what should be optimized. ) HTH, Loic.

Hello, loic-dev@gmx.net! You wrote on 21 Feb 2006 23:44:19 -0800: ??>> [skip] ??>> So, I'm planning to use semaphores. I think this is the only way? ld> No. Another possibility would perhaps be file locks. See e.g.: ld> http://www.gnu.org/software/libc/manual/html_node/File-Locks.html Yes, forgot about it. But seems like semaphores mechanism is more portable. Am I wrong? With best regards, Roman Mashak. E-mail: mrv@tusur.ru