Yes if your targetSdkVersion is >= 12, then as of that release the default executor is serial.
This change was made because we realized we had a lot of bugs in the platform itself where async tasks where created that had implicit ordering dependences, so with the default parallel execution there were subtle rare bugs that would result. I can't address how much smarter you are than the rest of us, but I am pretty convinced that for the vast majority of us the best thing to do is have the default here be safe, allowing developers to change it for the specific cases where they don't want that behavior. This is a lesson I seem to learn every few years: multithreading is hard. Once you think you now understand it and are an expert, you are heading soon to another painful lesson that multithreading is hard. Having an API to set the default executor back to parallel is not a solution, because it just gives you an easy way to create the exact same problems we are trying to fix. For example, if you have an async task that executes due to some user input to update some data, there is a very very good chance that if you allow these to be parallel you will have a bug. Even with something as simple as a check box (which is one of the real cases that drove this change) you can have this problem. If you run an executor to save to disk the new state of the check box, there *are* situations where if you tap long enough and the CPU is loaded in the right way, you will end up with the first state being saved after the second. So, yes, the default is serial, and you must explicitly decide when to use a parellel executor. You should only use a parallel executor when you know this is what you want and it is safe: when it is something that can take a significant amount of time, and you know has no dependencies with any other background tasks you may execute. So in your example here, the solution is to run your download task with AsyncTask.THREAD_POOL_EXECUTOR and leave the others with the default serial executor. On Fri, Apr 20, 2012 at 12:16 PM, Nathan <[email protected]> wrote: > Still adjusting to the changes in Android 4.0 regarding AsyncTask. > > If I understand right, the default behavior of execute is changing to one > single thread pool with only one thread? With the reason cited that > programmers are not capable of handling a bigger threadpool (I'm > paraphrasing). > > Does that mean, that absent some code changes, all asynctasks inside a > process will only happen sequentially? > > So therefore, if I have a service running DownloadDictionaryTask in the > background, and the user chooses a menu item that starts > CheckDiskSpaceTask, the progress bar will cycle without any progress > because the task never makes progress? > > A user and I could briefly reproduce a situation where, as far as I could > tell, no asynctasks were running, yet my AsyncTask would not even start. In > this case, I couldn't even get one thread. Alas, I cannot reproduce that > situation, which appeared to fix itself without any code changes. > > But in any case, this isn't really acceptable to have only one asynctask > task run at once. But there is no central way to control that behavior, is > there? I would have to replace 83 instances of task.execute with > task.executeonExecutor. Since the above method is only available in SDK>11, > this isn't a one line change - it's more like 10-20 lines of code with > reflection, and some extensive testing. > > In my opinion, this a deplorable punishment for those developers who have > dutifully followed the AsyncTask pattern, which, to this day, the Android > platform has encouraged. > > Or perhaps I am reading this wrong. Maybe all DownloadDictionaryTasks > share one pool, and all CheckDiskSpaceTasks share another pool. In that > case, the rule is that only one task *of the same concrete type* can run at > once. This rule, I can probably live with, as I've used my own threading > pools for tasks that are truly data parallel. > > Can anyone enlighten me more? > > Nathan > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
