Skip to main content

Android C++ reference counting, part 2

In last article, we introduced the strong pointer, or sp. Today, we will take about another type of smart pointer - weak pointer, or wp as called in Android. Let's look at an example.

using namespace android;

// class Memory subclass RefBase so it can be reference counted
// and be accepted by both sp<T> and wp<T>, where sp stands for
// strong pointer and wp stands for weak pointer. 
// A weak pointer won't prevent the object it points to from being 
// deleted - as long as there is no strong pointer pointing to the 
// raw object it will be deleted. Hence, to make sure the raw object
// is still valid, you will first need to promote it to be strong 
// pointer first. If the promote success, use it; otherwise, you know
// underlying object is no longer valid and you won't want to use it.  

class Memory: public RefBase {
public:
    Memory(int size) : mSize(size), mData(NULL) {
        ALOGD("        Memory constructor %p ",this);
    }

    virtual ~Memory() {
        ALOGD("        Memory destructor %p", this);
        if (mData)  free(mData);
    }

    virtual void onFirstRef() {
        ALOGD("        onFirstRef on %p",this);
        mData = malloc(mSize);
    }

    int size() {return mSize;}
private:
    int mSize;
    void *mData;
};

// used as a MARK in the output
#define L(N)   ALOGD("LINE %d TRIGGER:",N);
// print out the strong counter numbers of the object
#define C(obj) ALOGD("        Count of %p : %d", (void*)obj, obj->getStrongCount());

int main()
{
    wp<Memory> wpm1;
    Memory *m = new Memory(1);
    {//scope for spm1
        // create a Memory instance and let it be managed by a sp
        L(1)
        sp<Memory> spm1(m); 
        // assign the sp to the weak pointer, wpm1
        wpm1 = spm1;

        { // scope for spm2
            // You can't access wp's underlying raw pointer directly, since
            // there is no accessor apis defined for it.
            // Recall that for sp, there are three accessor apis/operators
            // you can use: get(),*,->
            // To access the raw pointer the wp pointing to, you need first
            // promote it to an sp, and use the returning sp if it is not NULL.
            sp<Memory> spm2 = wpm1.promote();
            if (spm2 != NULL) {
                L(2)
                ALOGD("        Promotion to sp successfully");
                spm2->size();
                // ref count is 2, since both spm1 and spm2 pointed to it
                C(m)
            }
        }
        // at this point, spm2 is out of scope, ref count of the m becomes 1 
    }
    // Beyond previous close curly, spm1 was also out of scope.
    // Since there was no strong pointer to m, m was destroyed.
    // Hence, following promotion will fail and we should not try to
    // use it any more.
    L(3)
    sp<Memory> spm3 = wpm1.promote();
    if (spm3 == NULL) {
        ALOGD("        Promotion Fail. Object already been destructed");
    }

    L(-1)
    return 0;
}

And, here is the output.

LINE 1 TRIGGER:
        Memory constructor 0x5597001050 
        onFirstRef on 0x5597001050
LINE 2 TRIGGER:
        Promotion to sp successfully
        Count of 0x5597001050 : 2
        Memory destructor 0x5597001050
LINE 3 TRIGGER:
        Promotion Fail. Object already been destructed
LINE -1 TRIGGER:

You maybe wondering what is the usage of weak pointer.  Here are two examples:
  1. hold a weak reference to observers. Only notify observer when it is alive.
  2. To solve the memory leak issue involved in the circular strong reference. Suppose A hold a strong reference to B and B hold strong reference to A. Then, neither A or B will be destroyed since there is always one strong reference to them. One of the solution is to make one of reference be weak reference.  
To wrap up, you may want to check out c++11 newly introduced std::shared_ptr and std::weak_ptr. The first one maps to sp and the later wp.

Popular posts from this blog

Android Camera2 API Explained

Compared with the old camera API, the Camera2 API introduced in the L is a lot more complex: more than ten classes are involved, calls (almost always) are asynchronized, plus lots of capture controls and meta data that you feel confused about.

No worries. Let me help you out. Whenever facing a complex system need a little bit effort to understand, I usually turns to the UML class diagram to capture the big picture.

So, here is the class diagram for Camera2 API.




You are encouraged to read this Android document first and then come back to this article, with your questions. I'll expand what is said there, and list the typical steps of using camera2 API. 

1. Start from CameraManager. We use it to iterate all the cameras that are available in the system, each with a designated cameraId. Using the cameraId, we can get the properties of the specified camera device. Those properties are represented by class CameraCharacteristics. Things like "is it front or back camera", "outpu…

Java Collections Framework Cheat Sheet

Java Collections Framework (JCF) implements the Abstract Data Type  for Java platform. Every serious Java programmer should familiar himself on this topic and be able to choose the right class for specific need.  A thorough introduction to JCF is not the target of this small article and to achieve that goal you can start with this excellent tutorial . 

Instead, I'd like to
1) Provide an overview of JCF's classes ,   2) Provide a cheat sheet you can post in your cubicel for daily reference, 3) Underline the relationship between JCF's implementation and the data structure and algorithm you learned in your undergraduate course

With these goals in mind, I came up following diagram - Java Collection Cheat Sheet. You can click it to zoom in. There is no necessity for more explanation once your familiar with UML class diagram and have a basic understanding of common data structures.


Android Security: An Overview Of Application Sandbox

The Problem: Define a policy to control how various clients can access different resources. A solution: Each resource has an owner and belongs to a group.Each client has an owner but can belongs to multiple groups.Each resource has a mode stating the access permissions allowed for its owner, group members and others, respectively. In the context of operating system, or Linux specifically, the resources can be files, sockets, etc; the clients are actually processes; and we have three access permissions:read, write and execute.