Ok... Since this is the first time I've done something like this I need help. If I want an application that will basically run 2+ applications at the same time should I use pthread or fork(). Now here's the harder part, I need each of the new "applications" to access linked lists (or BST's haven't chosen that part yet). The thing I don't know most of is if I should run with fork() and if so; how can I share the memory addresses so that they can both access the same Linked Lists. Or if I should use pthread which I'm not even sure if it will run truly parallel. Help would be most appreciated. The last concept (since this is a program that will have many different client connections, and each server -> client connection will be like it's own program) would be to have the main program fork() for X_max_connections where each connection will be a new thread in that child. -Root

EDIT: I just saw this was in "For beginners". I'm not sure how much you know about threading, seperate processes, synchronization, etc., but if you aren't sure what some of the stuff I'm talking about means just ask because I assumed you knew the basic terms like processes, dead locks, threads, etc.

C/C++ isn't a language (just like French/English isn't). What language do you use?

Quote:Or if I should use pthread which I'm not even sure if it will run truly parallel.

Single core processors can't truly run anything in parallel (well at the level that you're coding; instruction-level parallism is common on modern processors). Both processes and threads seems to run in parallel to the user though.

It all depends on your platform. Judging from the options you mentioned (pthreads and fork) I assume you are on some Unix-like operating system, maybe Linux.

If they are truly seperate applications then you should fork your process, but if they are just seperate execution streams then you should use threads. The fact that you want to share data structures between them seem to suggest that they aren't completely seperate applications, so you should probably use a thread. There are very few problems for which forking is the best option.

Sharing with threads is just done by making the data visible to both threads and then accessing it. Of course you need to synchronize the access since you don't want to encounter dead locks, race conditions, starvation and all the other common threading bugs out there. You should remember that a lot of shared state is considered bad design and can lead to strange bugs.

If you do choose to create seperate processes then you need some kind of sharing mechanism. Depending on your platform there are several options like message passing and shared memory. This can get pretty complex, but seperate applications should rarely share state anyway.

Quote:The last concept (since this is a program that will have many different client connections, and each server -> client connection will be like it's own program) would be to have the main program fork() for X_max_connections where each connection will be a new thread in that child.

How many connections are you expecting and what kind of work do you need to do? New processes would almost certainly be way too expensive to use for every connection. Threads may be a good option, but in many cases even a single thread per connection proves to be fairly expensive.

I think you need to state a little more clearly what you mean by "like a seperate application" and on what platform you're.

You may also want to look at Boost.Thread.

If the two "applications" are truly separate in thought then use two different apps and fork and use pipes for communication. If it is more along the lines of a server which you mention in the next paragraph go with threads they are much more light weight and more along the lines you are looking for. Then you have very fast shared memory for IPC.

Mechanisms for sharing the data are the least of your problem. They are also very platform specific.

Designing algorithms that would take the advantage of it are. How will you synchronize the data across the process? What happens if one process (possibly the owner of data) dies? What happens if one or more of the processes are started.

All this talk about fork and pthread makes me think Linux. Shared memory is a nice solution for that. But it comes bare-bones, and it takes quite some caution to synchronize everything. There's also a lot of captchas when linking the applications and managing ownership of the data.

I also don't know what relevance the Linked List in particular has, but linked list algorithms for parallel processing exist.

Perhaps rather than talking about algorithmic details you describe what you're trying to achieve.

Server forking each connection seems somewhat redundant. Having thread-per-connection is more than sufficient, and you'll be getting performance problems regardless of whether connections are threads or processes.

Also - pthread is a thread library. It's not parallel or anything, it provides access to threading primitives. These allow you to write multi-threaded applications. Whether they are parallel or not is irrelevant - your application behaves as if it were truly parallel - if it is depends solely on hardware it's running on and how it was compiled. It's as good as it gets on commodity hardware.

The only other way of parallelism in today's household hardware would be GPU or SSE/SIMD, which are true vector operations. They are also extremly limited in feature set.