I'm just looking for a little info on the differences between IPC and POSIX shared memory segments. I assume, as with most things, POSIX will be the eaiser to impliment. However, I am looking for the most control over these memory segments as possible and simplicity is not a necessity.
Furthere more, do either of these implimentations allow for changes in the segment size after creation. I wish to start putting some dynamically sized lists into shared memory and be able to identify when the segment is full and grow accordingly.
I appreciate any insight that might come my way on this issue.
This should probably be moved to the Linux Programming forum, shared memory isn't a feature provided by the C language, it's a platform specific implementation.
That said, IPC stands for "Interprocess Communication". It's a generic term referring to the set of methods used to communicate between two processes, such as via a socket, a pipe, shared memory, signals, rpc, fifos, et cetera. I'm not sure what you mean by "differences between IPC and POSIX shared memory segments". Perhaps you meant SYSV and POSIX?
Anyway, I'm not sure if either of them allow a size change.
IPC means Interprocess Communication, it's not a standard like POSIX.
Your question is very broad. I don't know what control means - controlling type of access?
Synchronization that uses Mutexes/semaphores? What you should seriously consider is reading :
Chapter 15 in 'Advanced Programming in the UNIX Environment' by R Stevens.
Ok then, let me rephrase a bit.
My question was geared toward fining out what people preferred to use when doing a great deal of work with shared memory and any tricks that have helped them organize their implimentations.
By "the differences between IPC and POSIX shared memory segments" I simply meant does POSIX bring anything to the party that really makes it usefull.
The point of posting to a message board like this is not get my post blasted and told to go look in a textbook. Rather to get some insight that isn't in the books and hear what your opinions are.
Short answer: yes. However you need to let the requirements of your application dictate what approach you should use, not what one of here thinks is more interesting or cool or has better features.
For example, does it have to be portable? - if so, then POSIX compliance is your only hope to ameliorate painful migration or even more painful multi-platform development.
Cool was not the question!!! Once again I have discovered the uselessness of messageboards. I am a well educated programmer simply asking for a bit of discussion about experiences and opinions.
I am very aware that situation dictates implimentaion.
So if you people want to stop telling me how dumb my question is. Here is some more detail about my 'situation'
I work with a suite of processes that were developed in the 1980s and are slowly being revamped. All of these process interact with an oracle database. While most of our code has been modernized, many of the background workings still pass info between each other using tables in the databse. This is very timne consuming and as the rest of our software has reached a very efficient state, these countles Pro C sql queries have become a burden to the whole system.
Shared memory has been used many in many places but only for small sets of static sized data. The advantage of using the Oracle tables is they are inhearently dynamic in size.
My current project is to migrate as many of these database sharing situations into more usefull shared memory segments. I need to write a library that monitors the segments and the data within them allowing for chages in the segment sizes as well as just providing basic attaching, dettaching, creation and destruction.
This being my situation I am just asking for some thoughts about how to approach this. I certainly have my own ideas I just find it usefull to have several points of view on a project so that I may see problems before they arise.
There are a lot of posts here from folks who can't spell C.
I think if you had put paragraphs 4 & 5( fronm your last post) in at the start, we could have skipped the other crud.
If information is being passed as you describe, will message queues meet your needs?
There are fewer restrictions with this approach than others.
Shared memory is not dynamic, memory mapped files are dynamic. Memory mapped files have one problem, the memory they reference is generally limited to the process (and it's children) that created the memory mapping for the file. File mappings do not persist across exec calls, so forget that.
We are Oracle, we use shared memory for some things. If we require dynamic allocations it has to be files (named pipes), pipes, message queues. Message q's are the fastest choice here. If you're on FreeBSD message q's have pretty strict limits on the number of messages in a given queue. In general, the implementation of message q's is quite variable, even though there are "POSIX" standards they are supposed to comply with.
Linux is good about message queues IMO, while MacOs does not support 'em at all, AFAIK.
> Once again I have discovered the uselessness of messageboards.
If you want many more professionals then try www.tek-tips.com
This board is largely aimed at students who are just starting out, so there are in fact very few seasoned pro's here, and even less who could offer a meaningful opinion.