Hacker News new | past | comments | ask | show | jobs | submit login

One problem with the type of approach here is that many modern UI programs allocate objects on side threads and then migrate those objects to the main thread (which is the only thread allowed to touch UI state). So truly, one needs to have an approach that allows for that steady state to be recognized (the steady state being when the object has landed in its final destination thread).

Once swift has some sort of concurrency model, it would be interesting to see if we could use per thread local ref counts that manage the lifetime of a single atomic ref count bump. One would be able to convert in between the two types of ref counts upon escape if needed.

This type of approach would eliminate most of the ref counts and allow for all threads to use in hot code these non-atomic thread local ref counts.




I only skimmed the paper, but it seems like the proposed method could support handing over ownership from the worker thread to the GUI thread via an explicit statement in the code.


Yeah. Event at runtime, it seems possible when the owner thread gives up the ownership (by setting owner_tid = 0) can use an extra flag to let other threads to compete for the ownership. As long as the flag is on the 2nd half-word, (it seems) there is no atomic requirement for the 1st half-word.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: