Page 1 of 2

questions about threads

Posted: Sat May 31, 2003 6:27 pm
by aszid
i'm working on a server & client network program, and i was planning on using multiple threads for the different parts of the program (i.e. one for the network handleing, one for the window-resizing, etc)

if i created a program that uses multiple threads, can i safely modify global variables, as long as i'm carefull not to change the same variable from 2 threads at the same time?

for example, if i created another global variable that basically just told me if a different variable was currently in use, and checked this variable before i made any attempts to modify the other variable, would this be enough? or if i made a single procedure to make the variable changes for me, and in this procedure added code to ensure it wouldn't run twice at the same time?

i'm rather new to threads, so i don't really know what kinds of things would cause me problems, other than changing the same variable in more than one thread at the same time.

any tips/suggestions would be greatly appreciated.

Thanks in advance

Re: questions about threads

Posted: Sat May 31, 2003 8:39 pm
by ricardo
aszid wrote:if i created a program that uses multiple threads, can i safely modify global variables, as long as i'm carefull not to change the same variable from 2 threads at the same time?
Im affraid that is not a good practice, if im not wrong Fred said once that its not recommendable and safety.

Re: questions about threads

Posted: Sat May 31, 2003 9:57 pm
by tinman
aszid wrote:for example, if i created another global variable that basically just told me if a different variable was currently in use, and checked this variable before i made any attempts to modify the other variable, would this be enough?
No, because you do not know when the threads are accessing the global variable which tells you if the global variable is being accessed.
or if i made a single procedure to make the variable changes for me, and in this procedure added code to ensure it wouldn't run twice at the same time?
That would be one way, but you still need a correct method to prevent possible multiple modifications.
i'm rather new to threads, so i don't really know what kinds of things would cause me problems, other than changing the same variable in more than one thread at the same time.
Anything which is shared between threads is a possible source of problems. I'm currently working on something for this, but I do not know when it will all be finished. I'll upload a beta version of it somewhere and post here when I have done so (if you are interested).

Posted: Sun Jun 01, 2003 2:19 am
by aszid
thanks for all the responses.

one thing i want to clarify though, is the one method i was talking about, using a 2nd global variable.... i was actually thinking of having more than one extra variable, and each one of them would only be changed from one thread. anyhow.. i'll come up with a sample source of it tonight or tomorrow to show you what i mean (and to try it out)

Posted: Sun Jun 01, 2003 5:35 am
by Insomniac
I have also researched this through the forum in the past as I wanted to make a multi-threaded file copier.

From what I could tell global variables were considered thread safe providing they were not strings, see code example by Francois Weil here:

viewtopic.php?t=2440

The recommended work around for this is to use structures as shown here:

viewtopic.php?t=4950

That's my interpretation (as a newb myself ) and my code works.

Perhaps the subject could be added to the PB documentation.

Regards

Insomniac

Posted: Sun Jun 01, 2003 11:09 am
by geoff
If you don't know exactly how the hardware and OS will schedule running the different threads then you could set up handshake communication between them.

So one thread would set a variable reserved to itself to ask permission to do something, then the other threads would set variables to acknowledge they have seen the request and agree to it.

If more than one thread makes a request before all the acknowledge responses are in, then they all back off and wait a random time before trying again.

A system like this will work even on a multiple processor system where processes run concurrently.

Posted: Sun Jun 01, 2003 1:59 pm
by dmoc
With respect, is this not what OS's are already designed to solve, ie, semaphores, critical sections, etc? In which case what is to stop PB programmers making use of them already? Example already exists on the resources site where you only wamt one instance of a program running. I think the file is actually called "runonce.zip". Just my 50p's worth, due to inflation :wink:

Posted: Sun Jun 01, 2003 2:44 pm
by geoff
Fair comment.

No need to program this if you're sure the OS does what you want.

Posted: Sun Jun 01, 2003 3:05 pm
by dmoc
Hey Geoff, my reply wasn't aimed at you specifically :lol:

Posted: Sun Jun 01, 2003 5:48 pm
by tinman
See here for something possibly useful ;)

viewtopic.php?t=6303

Posted: Mon Jun 02, 2003 6:51 pm
by geoff
A question.

Do you get worthwhile performance gains by breaking a large task into several threads? I'm sure you would with a processor that can run threads concurrently, like the latest P4, but it's not obvious to me that you would get a speed increase on a single CPU processor.

Has any one done speed comparisons between threaded and unthreaded routines?

Posted: Mon Jun 02, 2003 7:11 pm
by Pupil
geoff wrote:A question.

Do you get worthwhile performance gains by breaking a large task into several threads? I'm sure you would with a processor that can run threads concurrently, like the latest P4, but it's not obvious to me that you would get a speed increase on a single CPU processor.

Has any one done speed comparisons between threaded and unthreaded routines?
On single CPU systems, you should get worse performance as you have to share the CPU time between all the threads, shifting from one thread to another takes some CPU cycles(don't know how many). On multi CPU systems if OS handles things as i assume it does, there should be some gains...

I use threads for running long processing runs in the background, so the GUI is still accessible for the user.

Posted: Mon Jun 02, 2003 7:22 pm
by Fred
I can second the Pupil tough about this fact on a single CPU (Except HyperThread P4 of course).

Posted: Mon Jun 02, 2003 8:03 pm
by dmoc
Performance *can* be increased depending on your application, even on single cpu systems. Yes there is a slight hit while task/thread switching but this should not be a deciding factor (if it is then your into hard realtime solutions). Multi-threading is typically employed to increase responsiveness and in doing so can have a big hit on performance. The client-server scenario is a perfect case in point: imagine if every client had to wait while the server finished completely servicing the current client = unuseable system. Mutlithreading the server gives each client better response time, hence better performance, even though efficiency (time actually dealing with client rather than switching tasks) has gone down, poss significantly.

Posted: Mon Jun 02, 2003 8:18 pm
by tinman
dmoc wrote:client better response time, hence better performance,
It depends on whether you class "performance" as responsiveness or throughput. As you described in your example, responsiveness can be increased at the expense of throughput (on a single CPU system).