Hello, i have an AO and now i want to do another thread whith another implementation but they have to share info. Do I have to create a thread with the AO "inside"? how can i use same data in the thread and in the AO? thanks
Symbian is very memory specific and AOs are a key to that. In multi threading you will have to compromise on peformance as well, due to its overheads. Why don't you go for multiple AOs in the same process.
The main issue with multi-threading (on any system, not just Symbian) is that you need a whole lot of code to handle communication between the threads. Not to mention having to be extra careful when you access any data that is shared between the threads (always having to be aware that one thread can pre-empt another at any time). If you can solve your problem using multiple AOs running in your applications main thread you should do that instead.
No. Why have you got that idea in your head? You do not have to use threads at all and it will make your program unnecessarily complex.
You have already been told this more than once from your posting on forum Nokia, you should listen to what you have been told there and stop trying to get a 2nd opinion.
If you have a time critical work, it is better to let thread to do. for example, playing mp3(if you play mp3 using AO, there may
be lags). otherwise, AO is enough.
I tend to agree that threads should really only be used when necessary. However I'm currently thinking about something where I can choose between a 2 thread solution and a 3 thread solution. I've started looking at the two thread solution and I'm having trouble getting it working right. I'm getting CBase-42 errors (SetActive called when AO is already active) and it's getting me annoyed. They don't happen on the emulator and I gave up with "Symbian on-target debugging" years ago. So I'm left sitting here trying to guess which of my AOs is getting messed up. The 3 thread solution is actually a simpler design and it will have fewer AOs, making it a whole lot easier to debug. At least in principle it will, but I guess if I go down the extra thread route they'll be other issues.
Maybe I should just give up this job and go and do something else...
CBase-42 should be quite easy to avoid. Just check if IsActive and if is, do not request the asynch thing & call SetActive. Or just do User::Panic to really find out when this happens. Or print something to a log if you test on device and cannot use device debugging.
Thread debugging cannot be done properly in reality, since once you bring in the debugger, breakpoints etc, the scheduling is not the same. Also how the OS decides to schedule your thread also depends on the other threads in other processes. You will not be able to recreate troublesome situations at all. Everything is so much more complex. If you decide to take on threads, do not do it because you think debugging will be easier then. It will not be.
Thanks Andreas. "should be" is the key phrase here! I try to avoid putting in IsActive() checks if possible because the design for the code should include the knowledge of whether or not the AO is active in the first place. I know putting them in is good from a defensive programming point of view but at the same time you are potentially just hiding flaws / defects in your implementation and I prefer not to do that if possible. Fortunately I've now found the problem and my code is working properly
I guess what I was really complaining about is how much of a pain on Symbian it can be sometimes to track these things down. The reason I can't use on-device debugging is that my primary development environment is a fairly old version of Carbide.vs. About six months ago I tried upgrading to a more recent version of Carbide.C++ but that was a disaster, so I'm reluctant to try again as I know from experience with Nokia / Symbian that it's always one step forwards, one step back and several steps sideways! I just can't spare the time right now to install a new platform, get all my code working on it, and then find out that it has a whole bunch of new weird problems / issues that you have to figure out and get used to.
Don't get me started about on-target debugging. I was there "at the beginning" when this was mentioned as one of the reasons for ditching MSVC and switching to CodeWarrior. Of course as we all discovered CodeWarrior couldn't do emulator debugging properly, never mind on-target debugging. Emulator debugging was something that MSVC handled flawlessly I might add. Maybe it's all working beautifully now and I should take another look, I just don't want to end up disappointed and getting all angry about the whole thing again.
Getting back to the original topic, from a beginners point of view the message is clear: Don't use threads if you can do the job with one or more AOs. At an intermediate / more advanced level the situation isn't so clear cut. My point was that in some cases using more threads may result in a better, simpler, more elegant design. This should then lead to a better, less complex, and more bug free implementation. That said I completely agree with you that adding threads is potentially far more hazardous than adding AOs. For me I've got already got 2 threads, so adding another one isn't anything like as big a deal as going from one thread to two. Except that each thread will have two other threads to communicate with instead of one. But that's more of a design challenge than an implementation issue.
One of the other things about multi-threaded programming is that it's all about the timing of events. Quite often the emulator is so fast that "bad things" just don't happen and your code behaves very differently when you put it on a phone. So as you said the scheduling really does make an enormous difference. If you've only got one thread and a bunch of AOs in almost all cases you'll be able to debug it on the emulator and it will work without issue when you put it on a phone. In my experience that almost never happens with multi-threaded code!
Forum posts: 462
You could check on an article :
http://wiki.forum.nokia.com/index.php/Synchronous_operations
Also try to search on IPC to get more material in NewLC and Forum Nokia
Forum posts: 132
Active objects are a replacement for threads, are you sure you need to create both more threads and more AO? I doubt it.
Forum posts: 61
Symbian is very memory specific and AOs are a key to that. In multi threading you will have to compromise on peformance as well, due to its overheads. Why don't you go for multiple AOs in the same process.
Forum posts: 110
The main issue with multi-threading (on any system, not just Symbian) is that you need a whole lot of code to handle communication between the threads. Not to mention having to be extra careful when you access any data that is shared between the threads (always having to be aware that one thread can pre-empt another at any time). If you can solve your problem using multiple AOs running in your applications main thread you should do that instead.
Forum posts: 26
thanks!
Forum posts: 132
No. Why have you got that idea in your head? You do not have to use threads at all and it will make your program unnecessarily complex.
You have already been told this more than once from your posting on forum Nokia, you should listen to what you have been told there and stop trying to get a 2nd opinion.
Why do you think you have to use threads?
Forum posts: 14
If you have a time critical work, it is better to let thread to do. for example, playing mp3(if you play mp3 using AO, there may
be lags). otherwise, AO is enough.
Forum posts: 132
runforu is correct, making a socket connection like you want to is not time critical, leave threads alone until you have to use them.
Forum posts: 110
I tend to agree that threads should really only be used when necessary. However I'm currently thinking about something where I can choose between a 2 thread solution and a 3 thread solution. I've started looking at the two thread solution and I'm having trouble getting it working right. I'm getting CBase-42 errors (SetActive called when AO is already active) and it's getting me annoyed. They don't happen on the emulator and I gave up with "Symbian on-target debugging" years ago. So I'm left sitting here trying to guess which of my AOs is getting messed up. The 3 thread solution is actually a simpler design and it will have fewer AOs, making it a whole lot easier to debug. At least in principle it will, but I guess if I go down the extra thread route they'll be other issues.
Maybe I should just give up this job and go and do something else...
Forum posts: 587
CBase-42 should be quite easy to avoid. Just check if IsActive and if is, do not request the asynch thing & call SetActive. Or just do User::Panic to really find out when this happens. Or print something to a log if you test on device and cannot use device debugging.
Thread debugging cannot be done properly in reality, since once you bring in the debugger, breakpoints etc, the scheduling is not the same. Also how the OS decides to schedule your thread also depends on the other threads in other processes. You will not be able to recreate troublesome situations at all. Everything is so much more complex. If you decide to take on threads, do not do it because you think debugging will be easier then. It will not be.
Forum posts: 110
Thanks Andreas. "should be" is the key phrase here! I try to avoid putting in IsActive() checks if possible because the design for the code should include the knowledge of whether or not the AO is active in the first place. I know putting them in is good from a defensive programming point of view but at the same time you are potentially just hiding flaws / defects in your implementation and I prefer not to do that if possible. Fortunately I've now found the problem and my code is working properly
I guess what I was really complaining about is how much of a pain on Symbian it can be sometimes to track these things down. The reason I can't use on-device debugging is that my primary development environment is a fairly old version of Carbide.vs. About six months ago I tried upgrading to a more recent version of Carbide.C++ but that was a disaster, so I'm reluctant to try again as I know from experience with Nokia / Symbian that it's always one step forwards, one step back and several steps sideways! I just can't spare the time right now to install a new platform, get all my code working on it, and then find out that it has a whole bunch of new weird problems / issues that you have to figure out and get used to.
Don't get me started about on-target debugging. I was there "at the beginning" when this was mentioned as one of the reasons for ditching MSVC and switching to CodeWarrior. Of course as we all discovered CodeWarrior couldn't do emulator debugging properly, never mind on-target debugging. Emulator debugging was something that MSVC handled flawlessly I might add. Maybe it's all working beautifully now and I should take another look, I just don't want to end up disappointed and getting all angry about the whole thing again.
Getting back to the original topic, from a beginners point of view the message is clear: Don't use threads if you can do the job with one or more AOs. At an intermediate / more advanced level the situation isn't so clear cut. My point was that in some cases using more threads may result in a better, simpler, more elegant design. This should then lead to a better, less complex, and more bug free implementation. That said I completely agree with you that adding threads is potentially far more hazardous than adding AOs. For me I've got already got 2 threads, so adding another one isn't anything like as big a deal as going from one thread to two. Except that each thread will have two other threads to communicate with instead of one. But that's more of a design challenge than an implementation issue.
One of the other things about multi-threaded programming is that it's all about the timing of events. Quite often the emulator is so fast that "bad things" just don't happen and your code behaves very differently when you put it on a phone. So as you said the scheduling really does make an enormous difference. If you've only got one thread and a bunch of AOs in almost all cases you'll be able to debug it on the emulator and it will work without issue when you put it on a phone. In my experience that almost never happens with multi-threaded code!