Re: Protected Objects And Many Processors

[Gene <gene.ressler@gmail.com>]

You mean using rendezvous instead of protected types?  With rendezvous you'd need a "server" task for each shared object to serialize operations on it. (You would not want to use the single connecting task shown in your diagram for this purpose because giving it different  jobs like this would decrease available parallelism.)  Even if there is no contention, every object access would require execution in two threads with this scheme. With protected types, only a single thread runs in the no-contention case.  

Queueing a thread on a lock and then restarting it would have to be free to erase the difference in cost. 

While it might be cheaper to queue and restart across cores and/or CPUs than to swap contexts in a single core, it will never be free, and the exact overhead will be extremely architecture dependent, including cache, OS (thread affinity policy especially), and RTL implementation.  You'd have to find out how bad the news is by studying documentation and finally by testing.  In most environments the protected type will still be considerably more efficient.  As its name implies, rendezvous is best for synchronizing execution control flow, passing at most one chunk of data between tasks at a time.