I have a number of functions which are processed sequentially
i.e.
Do function 1
then function2
then function 3
etc...
My question is how can I call function1 2 and 3 at the same time?
Any help greatly appreciated.
Printable View
I have a number of functions which are processed sequentially
i.e.
Do function 1
then function2
then function 3
etc...
My question is how can I call function1 2 and 3 at the same time?
Any help greatly appreciated.
Look up threading
>>> Look up threading
... which is OS dependent of course.
Technically, it's impossible to do what you want (unless you have your hands on a triple+ CPU system). The next best thing is multitasking. There are a couple of pre-built multitasking systems on the net you can use, or you can make your own.
What language are you using? If C/C++, there's one over at ProgrammersHeaven.com. Just search for multitasking and see what it yields...
if you use static data you can split the runtime of your program and have simulated parallel calling, though it remains wired in series, so to speak...
>>> The next best thing is multitasking.
Multitasking is not a substitute for multithreading. A multitasked system has each process running within it's own protected environment, and you have to jump through some hoops to get the tasks to share data etc. This is not the case with a multithreaded system where each thread maintains it's own register/PC/SP area and, (depending on the OS), possibly it's own stack, but the heap memory and other such things are shared implicitly.
I do not know BeOS, maybe it does not support multithreading, (unlikely I would have thought), but Windows, and *nix both fully support within task multithreading.
Of course, on a single processor system, only one thread is actually running at a time, but the OS timeslices threads within a task so it appears that the same program is doing several things at once.
>Multitasking is not a substitute for multithreading. A multitasked system has each process running within it's own protected environment<
Hmm, well let's define task, thread, multitasking, and multithreading here to avoid confusion.
TASK - A single "thread" of execution independent or can be dependent of other code.
THREAD - A single "thread" of execution dependent a TASK. The thread runs in the context of the TASK which created it.
MULTITASKING - The act of running one task on a single processor for a certain amount of time then switching to another task and running it and so on to give the affect of running multiple tasks at the same time.
MULTITHREADING - Bringing threads into the act of multitasking. Since each task is made up of one or more child processes (dubbed threads), we multitask within each task. Implementing this becomes very complicated.
A task does not have to be in a protected environment, although it usually is.
>and you have to jump through some hoops to get the tasks to share data etc<
Not necessary. Look up semaphores, pipes, or another type of interprocess communications (IPC).
There are different degrees of implementing multitasking. Therein lies the confusion amongst programmers. IMO, multithreading is a type (an advanced one at that) of multitasking. But, whatever. Call it what you wish, people. I'm just trying to help. :)
If writing a multi-threaded program in Java, do you need to worry about this dependecy? I myself, don't know; anyone?Quote:
>>> Look up threading
... which is OS dependent of course.
What's the difference between multitasking and multiprocessing?Quote:
>Multitasking is not a substitute for multithreading. A multitasked system has each process running within it's own protected environment<
Hmm, well let's define task, thread, multitasking, and multithreading here to avoid confusion.
TASK - A single "thread" of execution independent or can be dependent of other code.
THREAD - A single "thread" of execution dependent a TASK. The thread runs in the context of the TASK which created it.
MULTITASKING - The act of running one task on a single processor for a certain amount of time then switching to another task and running it and so on to give the affect of running multiple tasks at the same time.
MULTITHREADING - Bringing threads into the act of multitasking. Since each task is made up of one or more child processes (dubbed threads), we multitask within each task. Implementing this becomes very complicated.
A task does not have to be in a protected environment, although it usually is.
>and you have to jump through some hoops to get the tasks to share data etc<
Not necessary. Look up semaphores, pipes, or another type of interprocess communications (IPC).
There are different degrees of implementing multitasking. Therein lies the confusion amongst programmers. IMO, multithreading is a type (an advanced one at that) of multitasking. But, whatever. Call it what you wish, people. I'm just trying to help.
Are they the same thing? I always thought of a model where there were multiple processes running on your OS (i.e. Word and Excel at the same time); and within each of these processes you can have multiple threads (control of execution). So processes are really concerned with a "programs" area to work with (resources like memory etc..) and threads would involve the actual execution of program instructions (thus a non-multithreaded program actually has a thread but just a single thread). Also, I've heard of "fibers"; what are they?
Hi Hillbillie, I think this...
>>>
MULTITHREADING - Bringing threads into the act of multitasking. Since each task is made up of one or more child processes (dubbed threads), we multitask within each task. Implementing this becomes very complicated.
<<<
Is probably where I would probably differ. To me, a task is an entity which owns a stack, register/PC/SP save area, and a heap. A child process, (to me), is a similar entity. A single task running several threads does not have several seperate heaps.
>>> Implementing this becomes very complicated.
I would say it requires thinking about your programs in a different way, but once learnt, I don't think it is very complicated.
>>>
>and you have to jump through some hoops to get the tasks to share data etc<
Not necessary. Look up semaphores, pipes, or another type of interprocess communications (IPC).
<<<
Yes, semaphores, pipes shared memory partitions etc. are the kind of hoops I was talking about. With a multithreaded process, none of that is necessary since a heap variable visible from one thread is just as visible from any other. Thus if I is a globally scoped int, thread A can say X = I; and thread B can do the same x = I; and both would read the same value. No hoops!
skyline:
>>>
If writing a multi-threaded program in Java, do you need to worry about this dependecy? I myself, don't know; anyone?
<<<
Threading is very much an operating system dependent thing. The way Windows threads is not the same as *nix, which these days is more or less standardised on Pthreads. Some of the concepts are almost identical, mutex's for example, and with some juggling, you can emulate some features of one, with the other. Thus I suspect you could code a class library which implemented a threading model which was OS independent, (you can get a sawn off Pthreads for Windows for example), but they are at best emulations, and you tend to lose a lot of the performance benefits that you would hope for by threading in the first place!
OK Guys,
I appreciate the help
A few points to note
1) I am using C on Dynix
2) I don't seem to have a pthread.h or *thread* file of any kind
therefore will obviously have problems using threads.
3) However, can I use m_fork to accomplish my task?
>I would say it requires thinking about your programs in a different way, but once learnt, I don't think it is very complicated.<
Really? I'm still learning how to implement this. It's becoming more clear every day, but it's quite confusing! :)
>Yes, semaphores, pipes shared memory partitions etc. are the kind of hoops I was talking about.<
Ah, yes, well then I guess we agree there.
adrian, could you please tell me where you got all of this information. You seem to know your stuff about multitasking; do you have any books that you think would interest me? Thanks. :)
zeus:
>>> I am using C on Dynix
Don't know it, sounds UNIX'y.
>>> don't seem to have a pthread.h
Unfortunate. The Pthreads standard requires this header to be there and called that. Okay, so you probably don't have pthreads, but that does not mean you do not have a multithreading capability. (Windows, for example, does not require a special header to use the _beginthread() API). I guess it's down to the OS's and your compilers documentation/help/supplier/newsgroup.
>>> can I use m_fork
Possibly. fork() typically makes a copy of a running task, if you can inherit the address space of the original, then you might be able to acheive what you want. I'm afraid again, it comes down to the docs. Sorry mate.
Hillbille:
I'm afraid most of it comes from experiment, dissappointment, disallusionment, small flickers of insight, then repeat!
These days, I routinely multithread my Windows programs. My user interface runs in the main thread, and just about everything else gets delegated to worker threads. Keeps the interface fast and responsive - users like that.
Currently I am using OpenVMS, which has a pthreads type system, although, not a full implementation. There is a book by Dave Butenhof about pthreads which I read a while ago. Covers a lot of the ground, but remember, threading is very much involved with the OS. What applies in one system does not apply in others. Even the POSIX standard includes "ways to standardly be nonstandard" - think I'm kidding, research the "SCHED_OTHER" scheduling policy!
To both of you:
Some concepts in multithreaded programming are pretty universal, mutex's for example. If either of you want help implementing these things from a theoretical point of view, just ask again.
>I'm afraid most of it comes from experiment, dissappointment, disallusionment, small flickers of insight, then repeat!<
Haha, I know what you mean...
>Covers a lot of the ground, but remember, threading is very much involved with the OS. What applies in one system does not apply in others.<
Well, see that's my trouble. I'm trying to implement multitasking in my OS. I'm completely overwhelmed. I guess theory is what I'm interested in.
>If either of you want help implementing these things from a theoretical point of view, just ask again.<
I'm not really looking for help when it comes to actual programming (this is a one-person project.), but some resources would be great. :)