views:

21

answers:

1

The examples that I have seen of how to make a ContentProvider have all used the UriMatcher#match(Uri) method within the insert, query, update, and delete methods to easily handle all of the URI patterns that the content provider responds to (e.g.: http://developer.android.com/resources/samples/NotePad/src/com/example/android/notepad/NotePadProvider.html). This seemed okay to me until today, when I noticed on the ContentProvider API documentation that insert, query, update, and delete "can [all] be called from multiple threads". Additionally, the UriMatcher documentation says nothing about thread-safety or whether match is reentrant.

Do I need to worry about synchronizing calls to match on a shared, static instance of UriMatcher that is used within my implementations of insert, query, update, and delete?

A: 

Looking through the source of UriMatcher, it appears that multiple threads can call the match method simultaneously because the implementation of match only accesses the per-thread variable uri (the parameter), shared Strings, and elements of an ArrayList<UriMatcher> (via ArrayList#get(int), which is thread-safe).

addURI is not thread-safe because it structurally-modifies an ArrayList. It is the same ArrayList that match reads from, so addURI cannot be called while other threads are possibly calling match.

Daniel Trebbien