First of all I suspect your data source isn't an immutable object even if its public interface is , early versions of java
String suffered this issue there public interface allowed no change but actually they tried to sneak some internal change unfortunately this was a visibility issue for threads.
Now how does your data source come into life , how are those writes to get the data source to its initial state published to other threads, the data source could defend its self by synchronizing all methods kind of in the way all early java collections did but that has issues (see vector vs arraylist)
Consider your reference to the data source how does that come into life e.g. initialise to null then write new object reference (be careful just because your code looks one step it may not be thread atomic) what if that reference write is never seen by any of your non modifying, only reading threads, how can it defend its own reference (can be done synchronize the get reference, volatile reference ;-) ). See the double checked locking example at the end for some issues round 'just' reading a reference from another thread,.
If thread A modifies data source even in a synchronized way as you put it and thread B reads unsynchronized the rules are quite complex as to if thread B will see any of the changes made by thread A. In terms of synchronization is A and B should both synchronize on the same object.
Consider a very common example a thread A that runs polling a public member boolean variable initially true for changing to false, thread B sets this variable (via a synchronized method) to a new value false which thread A is intended to see and stop BUT thread A doesn't read via a synchronized so the write of B can be missed and it loops forever.
This a really complicated subject perhaps the most complex in java and the only way to learn it is to start with lots of simple code gotcha examples. My first recommendation is you don't learn it at all and stick to a few basic threading rules but if you do start by looking at the issues round the famous double checked locking idiom as covered in many books and web sites.
eg
double checked locking