llancet:

As with many questions, "it depends". Without knowing more about the problem(s) you're solving, no-one can give you a good answer. To me, the question sounds something like:

Hi, I'm considering getting a new vehicle. I've looked at a Ford Explorer, a Mazda Miata, a school bus, a Lotus Esprit, a Honda Prius, and a bicycle. Which one should I use?

Obviously, that would depend on *your* circumstances. If you were an outdoorsman who frequently camps in the mountains, the Explorer could be the best vehicle for you. If you just liked cruising country roads with the top down, the Miata would be far better.

With your problems, if sharing memory was the most important criterion, I might investigate using a single task driving a set of state machines. Depending on what you're trying to do, this might give you the best performance with everything shared. If you share only a little bit of data--but very frequently--then I might use threads. On the other hand, if you less frequently share more complicated data, then I might advise the use of forking and share the data via a database, an IPC class, or some such. Without context, it's quite easy to give advice that you'll find to be wrong for your situation.

...roboticus

Update: Oops! Minor edit: s/top down, would/top down, the Miata would/

Actually, quite complicated. I use concurrency in different situations:

Firstly, in order to take advantage of multi processor (I have a 12-core workstation), I want to run multiple programs (actually, NCBI blast) at one time. Currently, I solve this by create several perl threads, and run one program in each thread. It works well.

In another situation, I'm making a large ugly GUI program (uses Gtk2), and I want the GUI keep active while background work is running. However, there are some complexed data structure that need to be accessed by both the GUI and worker thread, so I really wants a "real" thread that shares everything by default, but not copying.