It would seem to me that using effects for concurrency currently has the problem that under Nimrod's implementation of deferred reference counting any assignment of the form ob.field = p or arr[i] = p where p is a reference is also is an implicit write to p's reference count.
This could be circumvented, of course, by making reference count updates thread-safe. The traditional approach for that has been to buffer increments and decrements and only update them while all threads are stopped; I'm also seeing experimental code in system/gc.nim (when hasSharedHeap is defined) that uses atomic increments and decrements.
Both could possibly affect performance: the buffering approach may lead to larger pause times, using atomic increments and decrements can generate considerable overhead over the non-atomic versions (especially when there's contention for the reference count).
The write tracking is an alternative for the current thread analysis pass which is based on abstract interpretation (http://en.wikipedia.org/wiki/Abstract_interpretation ) that is not modular and can't deal with indirect calls. So it's not about solving any GC-related problems.
It would seem to me that using effects for concurrency currently has the problem that under Nimrod's implementation of deferred reference counting any assignment of the form ob.field = p or arr[i] = p where p is a reference is also is an implicit write to p's reference count.
This is one problem but there are lots of others. One plan is to introduce shared ref and only these allow sharing so only updates of these would incur the overhead of some syncronization primitive.
The traditional approach for that has been to buffer increments and decrements and only update them while all threads are stopped;
I tried this once. It's so slow it makes me wonder if I got something wrong.