Programming

Thank you for the info and all your help.
FG

That's what I meant, you put it better. I meant that because it can intercept the stack at any time the code running just prior is unknown and therefore the state of the application's data is generally difficult to deduce.

Anyway, as I stated, and you agreed, it is really just personal preference which method is to be used. I dislike signals for such things as this. Besides, which signal do you use, user1/user2 there are no "sync" or "comm" signals. To me it just seems like a bad approach to use signals. But you're right, technically there is no "data" to necessitate a pipe. However one could argue that a signal is just another form a data, just transmitted through a different, and in my opinion less reliable, manner.

Well, for what its worth, don't take this as argumentative because its not meant to be. Debating personal preference is, however, sometimes worthless...so I guess I'll shut up now .

Thank you all for the help, decided to go with a shared memory solution:

Code:

#include <stdio.h>
#include <unistd.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <fcntl.h>

main(int argc, char* argv[]) {

	int res; /* child id */
	int i, j, m, n;
	int shm_id, shm_value, child_num;
	int fd;
	int write_value, num_char;
	int  *  shm_ptr;
	char buf [sizeof(int)];
	 
	if( argc!= 4 || ( (n=atoi(argv[1])) <= 0 ) || ( (m=atoi(argv[2]))  <= 0) ) {
        fprintf(stderr,"Usage: %s <n - number of processes> <m - times process prints> <file - name of file>\n", argv[0]);
        fflush(stderr);
		exit(1);
    }

	/*Open file for writing*/
	if( (fd = open(argv[3], O_RDWR | O_CREAT, 0755 )) == -1 ){
		fprintf(stdout, "Cannot open file name = %s\n", argv[3]);
		fflush(stdout);
		exit(0);
	}
	/* Init Shared memory */
	shm_id = shmget(IPC_PRIVATE, sizeof(int), 0666 | IPC_CREAT);
	
	/* Attach this process to shared memory buffer */
	if( (shm_ptr = shmat(shm_id, 0, SHM_W)) == (int *) -1 ){
		fprintf(stdout, "Cannot attach process to memory \n");
		fflush(stdout);
		exit(0);
	}
	*shm_ptr = 0;
	for(i = 0; i < n; i++) {
		 if( (res = fork()) < 0 ){
			fprintf(stderr, "Cannot create child %d \n",(i+1));
			fflush(stderr);
			exit(0);
		}

		 if(res == 0){
			/* attach shared memory to this child process */
			if( (shm_ptr = shm_ptr = shmat(shm_id, 0, SHM_R | SHM_W)) == (int *) -1 ){
				fprintf(stdout, "Cannot attach process to memory \n");
				fflush(stdout);
				exit(0);
			}
			child_num = i;
			for( j = 0 ; j < m ; j++ ){
				/* Read the value of the shared memory */
				shm_value = *shm_ptr;
				/*Keep reading from shared memory until the previous process has written value*/
				while (1){
					if( shm_value == child_num){
						break;
					}
					shm_value = *shm_ptr;
				}

				/*Write next child number into shared memory buffer */
				write_value = (shm_value + 1);
				num_char = sprintf(buf, "%d", write_value);
				write(fd, buf, sizeof(int));
				write(fd, "\n", 1);
				*shm_ptr = ((shm_value + 1)%n);
			}
			break;
		 }
		 
	}
	/* Remove shared memory */
	shmctl(shm_id, IPC_RMID, 0);
	close(fd);
	exit(0);
 }

Code tags added for readability -- Perderabo

your code would be more easily readable with tabs , to get them use the

[code]
code here
[/code]

this will look like this:

Code:

code here

Anyway, it seems as though you are entering an infinite while loop "polling" the shared memory for a change in the child. Then you are writing back to the shared memory in said child for another to pick it up. This is all being done without any semaphore protection and therefore it is possible that things could go awry.

At any rate, this polling makes inefficient use of the CPU cycles, IMO. While it gets your assignment done...I just wanted to point out that its probably not an effective way of doing it.

However, it looks like you got it done...congrats.

edit: looks like the child does the shared memory write...this is worse yet.

Thank you for the feedback,will take it into consideration.
"Because the child is "only reading" the data the semaphore is potentially unneeded, but theoretically a "partial write" by the server could be misinterpreted by the child"
-- Would the partial write matter if you are looking for a specific value?
Just trying to understand this stuff.
Thanks,
FI

Theoretically, yes...in practice, you'll probably never see it happen. However when, if, it does you'll be banging your head trying to figure out what went wrong if you don't have proper synchronization. In fact, in multi-process (multi-threaded) applications this is one of the single biggest coding isses, IMO. (More accurately trying to tune said access to a point where it is both reliable and fast).

Look at it like this:

You have multiple processing accessing memory, and therefore there exists the potential for the Kernel to "context switch" in the middle of an instruction. Now, depending on how the read or write is done depends on whether you see a problem.

Lets say your platform uses 32 bit integers. At the very least, on a hardware (CPU instruction) level, you can guarentee the atomic (i.e. single non-context-switchable operation) read/write of only 8 bits of data (more in most cases, but the minimum register size of any CPU used today is probably going to be 8 bits). The CPU intruction set, kernel, compiler, etc all come into play when knowing when gets done when read/writing an integer to/from said shared memory (or in fact any memory). If your architechture can guarentee the atomic read/write of said 32 bits then you're fine. You'll never have a problem because it would be impossible for the application to be switched during the read/write of an integer.

HOWEVER, if it can not, then application 1 could be in the middle of a read or write when the kernel context switches in application 2 and then this incomplete operation is potentially an issue.

The point is, you really don't know what's going on below you and therefore the possibility does exist for this to get confused. This is exactly why semaphores exists to protect and synchronize this access. This way an application knows when its reads/writes can be "safely" done.

For example, let's say a certain platform can only modify 16 bits of data at a time. To tinker with a 32 bit area would require two (or more) operations. If the Kernel allowed a context switch between them, then it'd be possible (although highly unlikely) for the following sequence of events:

process 1: read first 16 bits
process 2: write first 16 bits
process 2: write second 16 bits
process 1: read second 16 bits

now process 1's view is distorted.

While in practice this is probably NEVER going to occur, it could and bugs like these are very hard to track down because reproducing this case would be almost impossible. Best just to code it correctly to insure that everything is ok.

That cleared it up.
Thank you for the info and example,
FI