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?
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With