Why lock the mutex in setPosition/position, setSource/source etc.?

Because these variables are potentially modified and read in different threads.

setSource -- because even though QStrings are implicitly shared, Qt docs say not to write/read from the same instance of the object from multiple threads. It may be paranoia but according to Qt docs writing to d.source from one thread while another thread is reading d.source is not supported (I never actually checked in the Qt sourcecode to determine if it would work and is safe, though -- is it?).

setPosition -- because that variable is shared across threads and I believe qint64 writes aren't atomic on all architectures -- are they?

setPrecision -- can probably do away with it since I think int reads/writes are atomic on all architectures..

Qt docs say not to write/read from the same instance of the object from multiple threads. It may be paranoia but according to Qt docs writing to d.source from one thread while another thread is reading d.source is not supported

Wrong. If it's right, what is implicitly sharing used for? string assignment will delete the old data if reference is 0, or just replace the data ptr and the reader still keep old data ptr.

setPosition -- because that variable is shared across threads and I believe qint64 writes aren't atomic on all architectures -- are they?

No one else reads position value, just user. the position value is set in task object.

setPrecision -- can probably do away with it since I think int reads/writes are atomic on all architectures..

It's rarely changed by user when running a task

Wrong. If it's right, what is implicitly sharing used for?

Implicitly shared is still useful -- aside from the benefit you get with reference counting, thread-wise it is indeed thread-safe if you are holding two instances to the same underlying object. The implementation of copy-on-write is thread-safe provided the two wrapper instances are owned by different threads, etc.

However according to Qt docs not all objects can safely be written-to or modified if two different threads are accessing them.

I double-checked the implementation of QString and it at least appears to be safe for sharing across threads due to the way it updates its data and pointers in copy-on-write.

Classes such as QMap and QList however aren't safe to share across threads if you keep a handle to the same instance (and I think I ran into this bug in one of my other PRs, possibly).

So:

QList<int> a, b(a);

// ^^ both a and b above point to the same reference counted private implementation object

Thread 1: a.push_back(1); 
Thread 2: a.push_back(2); // unsafe if thread1 happens to access a at the same time.
Thread 2: b.push_back(2); // safe since reference counting and detach, etc of copy-on-write is implemented atomically

Anyway.. it appears you are right about QString though, and in the interests of trusting your expertise, I will go ahead and get rid of the locks.

I will go ahead and revise the code and remove the mutex as per your concerns and push another commit. Hopefully 2 commits in 1 PR is ok with you.

I pushed the changes you suggested -- if you decide to accept this PR (please do as it does fix a real hang bug!) -- let me know if you want me to squash the two commits into 1 commit.

Best regards!

you are right. it's safe only if accessing a copy. You don't need to add a lock in setter/getter because qt doesn't do it.