03-26-2013 02:38 AM
I have 5 (services tasks) to do simultaneously.
Now when I introduce a sixth one (Timer tasks: either scheduled once or at fixed rate), it is blocked.
Though I can run that service in an existing task, but that is sinchronous: unless and untill the other subtask is finished, you can not continue with this required new service task.
I want to know whethere there is a limitation on number of simultaneous working threads?
Though I have a threaded que as well, but that is also imposing a wait..
I know of thread pool executors as well, but that is not backward compatible..
Please enlighten me with the knowledge of concurrent threads in Blackberry.
Solved! Go to Solution.
03-26-2013 05:35 AM
Don't think this is a Thread limit error, you would have got a different message:
Personally I don't use Timer tasks because (un my opinion anyway) they are really just a convenient packaging of Threads and I would rather "package" my code myself. So one thing I would try is moving the code into a completely separate, non Timer Thread and see if that helps.
03-26-2013 05:41 AM
Actually I have just realized that your problem is most likely that you are using the TimerTask to perform long running activity. My understanding of the Timer processing is that it is really just a single Thread, that initiates its associated TimerTasks at the specified intervals. However, as it is just a single Thread, there can be only one TimerTask running at one time. So if you have a long running TimerTask, it will hold up any other TimerTasks that should also be run.
a) Use the TimerTask to initiate a Thread to perform the processing you require. Then the TimerTask will complete quickly and you will get subsequent TimerTasks started on time.
b) Don't user Timer for things that are long running, code these as Threads.
Personally I would go with the second option. But that is just personal preference.
04-04-2013 02:54 AM - edited 04-04-2013 02:55 AM
Threads help resolve some problems. But more there are threads, more they consume processor. Device becomes slow.
I have resolved the issues using invokelater, threads, and scheduler processing que of runnables.
Application goes slow, but is performing.
It is good idea to not to extend main class with timer task, but always issue a new instance of a class extending Timer Task, that was what blocking my threads.
04-04-2013 04:46 AM
Not sure I agree with this sentiment in full.
For an application to do what the user wants it to do, there is always a certain amount of work to be done.
For me, using Threads has not contributed to the slowing down of doing this work- quite the contrary. In my experience, using Threads to subdivide this work so that the essential parts can be done quickly (like the UI updates) and are not blocked by the non essential parts ( like the communication with the Server). This does require good design and communication between the different parts of the application - typically this has to be thought out before you start developing the application as trying to add this in to an existing application is problematic.
The idea of having a queue of Runnables that are processed by Worker Threads is very useful in my opinion - I would suggest that you could have a number of Worker Threads processing this queue.
The one area that I always deliberately bottleneck is image download and scaling - I will try to have a single Thread processing this because of the time it takes.
One thing I would be wary of in your solution is the over use of invokeLater. Perhaps ones of the reasons your Application is slow is the fact that you are now constrained by the Event Thread?
Finally I would encourage you to review your processing and look for places that can done more efficiently. Here are some ideas, I hope they are useful.
The first major thing to try to stop, if it is happening, is the garbage collector - if you are seeing the hourglass icon then you need to investigate this.
But given your description it would seem there is a processor element in here, so you need to look for things that you do more efficiently - like using StringBuffer not String for String manipulation.
One area that I find improves things significantly is to minimize changes that cause the UI to be re laid out. For example, if you have a Manager that is displayed on the screen, and you add 7 Fields to this Manager, then each time you do an add, it will re-layout the Manager - which is silly because the work will be repeated when the next Field is added. There are various approaches to this, including adding the Fields to a Manager, then adding the Manager to the screen - which is just one layout.
And the final thing I would focus on is your FIelds' paint methods. Make sure they do the absolute minimum amount of work, So don't scale images or create a Font in there, do this externally and have paint just paint().
Hope this helps, glad you are getting something that is working.
04-05-2013 03:38 AM
Now I feel no problem:
I am indeed using StringBuffers, and also using SingleInstance for major utilities and Screen classes.
I am not seeing the hourglass, but I am sure the response time is slow for the requests that go.
For Images factory classes are there for resizing, but these are blocking, hence I agree with using one thread.
For GC: I use less global variables and make sure they are static, and after work is done, I assign them null, and reuse the same object to initialize.
It is good to make new variables in local (init function) and assign to global.
So I feel I need to change my views on: "No. of threads may slow down the processor".
I have to agree with you.
This far I am happy with my coding techniques.
Thanks and regards.