Fixing SysV shared-memory would a complete waste of time, I think! I tend to agree, I've only used it as a learning experience. I tend to go with threads-shared-memory. IIRC SysV shared mem had a nasty habit of not destroying itself automatically, leaving these security gaps if you are not careful. I have seen some patches that address this problem, but threads are my first choice of tool now. I would be willing to bet that SysV shared-mem is faster than threads-shared-mem, if proper tests were done, but if you really need that kind of millisec speed increase, you should write it in c or assembly :-) . Of course, if you have to fork, instead of threading, SysV Shared mem still provides a good way of IPC between forked processes.
| [reply] |
| [reply] |
From what I gather, threads-shared-memory has to be copied once when it is read, that alone will make it slower by a millisec or 2, in my guestimation. But I'm just an intuitive zen hacker, not a OS engineer.
If you have some bechmark code please post it. A "subjective" view of how fast something is, can be very deceiving when dealing with millisecond differences, since the human brain works at such a slow speed. So I will stand by what I said, since all books claim (with justification) that shared memory is the fastest form of IPC. It is up to you to prove otherwise, since you challenge the conventional wisdom. It is similar to the argument whether interpreted code runs as fast as compiled code..... if you put it on a 2Ghz machine, you can't tell the difference, but there is a minute one. As far as shared memory being faster than a Berkeley Database, I think that is almost assured. How can calls to a disk-based database server be faster than reading directly from RAM? (Assuming a properly built system, and correctly written code)
| [reply] |