Android Asynctask Internals vis-a-vis half-sync half-async design pattern
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Android Asynctask Internals vis-a-vis half-sync half-async design pattern

on

  • 462 views

This document describes the internals of how Asynctask of Android works internally and its similarities with half-sync half-async design pattern as described in Pattern Oriented Software Architecture ...

This document describes the internals of how Asynctask of Android works internally and its similarities with half-sync half-async design pattern as described in Pattern Oriented Software Architecture or POSA2.

Statistics

Views

Total Views
462
Views on SlideShare
462
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Android Asynctask Internals vis-a-vis half-sync half-async design pattern Document Transcript

  • 1. Android Asynctask Internals vis-a-vis Half Sync Half Async pattern by Somenath Mukhopadhyay som.mukhopadhyay@gmail.com The way Asynctask has been implemented in Android, is an apt example of Half Sync ­ Half Async pattern described in Pattern Oriented Software Architecture or POSA2. First of all, let us try to understand what we mean by Half Sync­Half Async design pattern. Half Sync­ Half Async pattern is a specific way how we want to structure our threads in a multithreaded application. As the name suggests, in this pattern we divide the solution of managing multiple threads into two different specific zones ­ one is synchronous and the other is an asynchronous zone. The main thread communicates with a thread asynchronously and this thread is responsible for queuing multiple tasks in a FIFO order. This thread then pushes these tasks on the synchronous layer to different threads taken from a thread pool. These thread pools then execute these tasks synchronously in the background. The whole process can be depicted by the following diagram.
  • 2. If you are new to the terms Asynchronous and Synchronous in the conjunction of multithreaded application let me throw some lights on it. These can be best understood in a client­server architecture perspective. A synchronous function means it will block the caller of it and will return only after it finishes its task. On the other hand an asynchronous function starts its task in the background but returns immediately to the caller. When it finishes the background task, it notifies the caller about it asynchronously and then the caller takes action. The two scenarios have been depicted by the following two diagrams. Now let us dive deep into the Android’s Asynctask.java file to understand it from a designer’s perspective and how it has nicely implemented Half Sync­Half Async design pattern in it. In the beginning of the class few lines of codes are as follows:  private static final ThreadFactory sThreadFactory = new ThreadFactory() {         private final AtomicInteger mCount = new AtomicInteger(1);
  • 3.         public Thread newThread(Runnable r) {             return new Thread(r, "AsyncTask #" + mCount.getAndIncrement());         }     };     private static final BlockingQueue<Runnable> sPoolWorkQueue =             new LinkedBlockingQueue<Runnable>(10);     /**     * An {@link Executor} that can be used to execute tasks in parallel.     */     public static final Executor THREAD_POOL_EXECUTOR             = new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,                     TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory); The first is a ThreadFactory which is responsible for creating worker threads. The member variable of this class is the number of threads created so far. The moment it creates a worker thread, this number gets increased by 1. The next is the BlockingQueue. As you know from the Java blockingqueue documentation, it actually provides a thread safe synchronized queue implementing FIFO logic. The next is a thread pool executor which is responsible for creating a pool of worker threads which can be taken as and when needed to execute different tasks. If we look at the first few lines we will know that Android has limited the maximum number of threads to be 128 (as evident from private static final int MAXIMUM_POOL_SIZE = 128). Now the next important class is SerialExecutor which has been defined as follows: private static class SerialExecutor implements Executor {        final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnable>();        Runnable mActive;        public synchronized void execute(final Runnable r) {            mTasks.offer(new Runnable() {                public void run() {                    try {                        r.run();                    } finally {                        scheduleNext();                    }                }
  • 4.            });            if (mActive == null) {                scheduleNext();            }        }        protected synchronized void scheduleNext() {            if ((mActive = mTasks.poll()) != null) {                THREAD_POOL_EXECUTOR.execute(mActive);            }        }    } The next important two functions in the Asynctask is public final AsyncTask<Params, Progress, Result> execute(Params... params) {         return executeOnExecutor(sDefaultExecutor, params);     } and  public final AsyncTask<Params, Progress, Result> executeOnExecutor(Executor exec,             Params... params) {         if (mStatus != Status.PENDING) {             switch (mStatus) {                 case RUNNING:                     throw new IllegalStateException("Cannot execute task:"                             + " the task is already running.");                 case FINISHED:                     throw new IllegalStateException("Cannot execute task:"                             + " the task has already been executed "                             + "(a task can be executed only once)");             }         }         mStatus = Status.RUNNING;         onPreExecute();         mWorker.mParams = params;         exec.execute(mFuture);         return this;
  • 5.     } AS it becomes clear from the above code we can call the executeOnExecutor from exec function of Asynctask and in that case it takes a default executor. If we dig into the sourcecode of Asynctask, we will find that this default executor is nothing but a serial executor, the code of which has been given above. Now lets delve into the SerialExecutor class. In this class we have final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnable>();. This actually works as a serializer of the different requests at different threads. This is an example of Half Sync Half Async pattern. Now lets examine how the serial executor does this. Please have a look at the portion of the code of the SerialExecutor which is written as  if (mActive == null) { scheduleNext();             } So when the execute is first called on the Asynctask, this code is executed on the main thread (as mActive will be initialized to NULL) and hence it will take us to the scheduleNext() function. The ScheduleNext() function has been written as follows:   protected synchronized void scheduleNext() {             if ((mActive = mTasks.poll()) != null) {                 THREAD_POOL_EXECUTOR.execute(mActive);             }         } So in the schedulenext() function we initialize the mActive with the Runnable object which we have already inserted at the end of the dequeue. This Runnable object (which is nothing but the mActive) then is executed on a thread taken from the threadpool. In that thread, then "finally "block gets executed. Now there are two scenarios. 1. another Asynctask instance has been created and we call the execute method on it when the first task is being executed. 2. execute method is called for the second time on a same instance of the Asynctask when the first task is getting executed. Scenario I : if we look at the execute function of the Serial Executor, we will find that we actually create a new runnable thread (Say thread t) for processing the background task.
  • 6. Look at the following code snippet­    public synchronized void execute(final Runnable r) {            mTasks.offer(new Runnable() {                public void run() {                    try {                        r.run();                    } finally {                        scheduleNext();                    }                }            }); As it becomes clear from the line mTasks.offer(new Runnable), every call to the execute function creates a new worker thread. Now probably you are able to find out the similarity between the Half Sync ­ Half Async pattern and the functioning of SerialExecutor. Let me, however, clarify the doubts. Just like the Half Sync ­ Half Async pattern's Asynchronous layer, the  mTasks.offer(new Runnable() { .... } part of the code creates a new thread the moment execute function is called and push it to the queue (the mTasks). It is done absolutely asynchronously, as the moment it inserts the task in the queue, the function returns. And then background thread executes the task in a synchronous manner. So its similar to the Half Sync ­ Half Async pattern. Right? Then inside that thread t, we run the run function of the mActive. But as it is in the try block, the finally will be executed only after the background task is finished in that thread. (Remember both try and finally are happening inside the context of t). Inside finally block, when we call the scheduleNext function, the mActive becomes NULL because we have already emptied the queue. However, if another instance of the same Asynctask is created and we call execute on them, the execute function of these Asynctask won’t be executed because of the synchronization keyword before execute and also because the SERIAL_EXECUTOR  is a static instance (hence all the objects of the same class will share the same instance… its an example of class level locking) i mean no instance of the same Async class  can preempt the background task that is running in thread t. and even if the thread is interrupted by some events, the finally block which again calls the scheduleNext() function will take care of it. what it all means that there will be only one active thread running the task. this thread may not be the same for different tasks, but only one thread at a time will execute the task. hence the later tasks will be executed one after another only when the first task complets. thats why it is called SerialExecutor.
  • 7. Scenario II: In this case we will get an exception error. To understand why the execute function cannot be called more than once on the same Asynctask object, please have a look at the below code snippet taken from executorOnExecute function of Asynctask.java especially in the below mentioned portion:   if (mStatus != Status.PENDING) {             switch (mStatus) {                 case RUNNING:                     throw new IllegalStateException("Cannot execute task:"                             + " the task is already running.");                 case FINISHED:                     throw new IllegalStateException("Cannot execute task:"                             + " the task has already been executed "                             + "(a task can be executed only once)");             }         } AS from the above code snippet it becomes clear that if we call execute function twice when a task is in the running status it throws an IllegalStateException saying “Cannot execute task: the task is already running.”. if we want multiple tasks to be executed parallely, we need to call the execOnExecutor passing Asynctask.THREAD_POOL_EXECUTOR (or maybe an user defined THREAD_POOL as the exec parameter. Now its time for experimentation to justify whatever we have discussed so far is correct or not. Lets create an Android project. Make the minimum SDK version more than 12 say 14. And the target SDK version, say 17. Then lets make the two classes derived from Asynctask as follows. public class MyAsynctaskWithDelay extends AsyncTask<String,Void,Void> { @Override protected Void doInBackground(String... arg0) { // TODO Auto­generated method stub System.out.println(arg0[0] + "before sleeping of AsyctaskWithDelay.."); try { Thread.sleep(10000); } catch (InterruptedException e) { // TODO Auto­generated catch block e.printStackTrace(); } System.out.println(arg0[0] + "after sleeping of AsyctaskWithDelay.."); //System.out.println(arg0[0]);
  • 8. return null; } } AND public class MyAsynctaskWithNoDelayLoop extends AsyncTask<String,Void,Void> { @Override protected Void doInBackground(String... arg0) { // TODO Auto­generated method stub System.out.println(arg0[0] + " The task with no delay..."); //System.out.println(arg0[0]); return null; } } Now in the main Acivity class, add these following lines of code. MyAsynctaskWithDelay asynctask1 = new MyAsynctaskWithDelay();         MyAsynctaskWithDelay asynctask2 = new MyAsynctaskWithDelay();         MyAsynctaskWithNoDelayLoop asynctask3 = new MyAsynctaskWithNoDelayLoop();         MyAsynctaskWithNoDelayLoop asynctask4 = new MyAsynctaskWithNoDelayLoop();         asynctask1.execute("Asynctask 1");         asynctask2.execute("Asynctask 2");         asynctask3.execute("Asynctask 3");         asynctask4.execute("Asynctask 4"); Now if we run this application we will find that tasks are executing serially. And the output will be like the following: 12­03 23:33:08.535: I/System.out(784): Asynctask 1before sleeping of AsyctaskWithDelay.. 12­03 23:33:18.594: I/System.out(784): Asynctask 1after sleeping of AsyctaskWithDelay.. 12­03 23:33:18.595: I/System.out(784): Asynctask 2before sleeping of AsyctaskWithDelay.. 12­03 23:33:28.601: I/System.out(784): Asynctask 2after sleeping of AsyctaskWithDelay.. 12­03 23:33:28.605: I/System.out(784): Asynctask 3 The task with no delay... 12­03 23:33:28.605: I/System.out(784): Asynctask 4 The task with no delay...
  • 9. As you see from the output, the tasks are being executed in accordance to the sequence of their calling of execute() function. Hope this helps the Android learners.