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 String
s, 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