Unix process synchronization without pthreads/sempahores, signals?

I am attempting to write a program that doesn't use pthreads or semaphore libraries. I want to do some synchronization with signals. I have read about them in a few Unix books, but I still don't quite get it. I wrote up some mock program design/code, this isn't my program but it gives an idea of how I am trying to organize processes/signals. Does this seem like a plausible solution?

Program Flow:

Main forks a random number of times, and executes "p开发者_开发百科rogram" in each child. The program assigns a value to the child, 1 or 2 (such as input or output etc.).

I want a way to synchronize these children. I thought using signals could be possible, and from what I read I would want to do something like:

If child == 1, send parent (main) SIGUSR1, else if child == 2 send parent (main) SIGUSR2. When the parent services the signal, then end.

Now back in main I want to organize these incoming signals. I would only accept one type at a time, so if a child sends me SIGUSR1, I will block all SIGUSR2s, or if a child sends me SIGUSR2 first then I block all SIGUSR1s. Main will receive the signal and service all signals of that type until there are no more of that type, then it will check/unblock the other type and service any of that type if they exist, else main will wait for more signals.

Does this seem like a proper use of signals and is this even possible with signals?

Thanks!

You don't say why you want to use signals. Are you just trying to figure out how signals work?

Does this seem like a proper use of signals and is this even possible with signals?

I wouldn't approach the sort of design you've presented with signals in mind. You don't say what the children are doing, but I might use pipes, or sockets, or perhaps message queues.

If you can add some information about your high-level goals, I may be able to offer you some better direction.