kus.bank at gmail.com
Sat Dec 12 19:03:43 EST 2009
Btw it seems I can avoid this whole dependence on fetch_and_increment by
using timestamp (there appears to be a lot of flame about how fast and
efficient gettimeofday is on various OSes need to catch up)
But the thing I realized is that in the strictest form, ticket locking has a
problem. It is really a spinlock where one thread can succeed and `n' others
are doomed to failure by virtue of ordering. yet the doomed threads will
occupy context timeslice on the processor by pause or continous spin cycles.
Instead if I did group ticketing (all threads with tickets less than 40 can
go for the spinlock now whoever wins wins ) ones above 40 please wait till
the current ticket is 40, this provides a bracket of fairness and doesnt
restrict performance. If I replaced the fetchAndIncrement with gettimeofday
based counter then the two problems seem to gel well and I get to avoid the
<just random thoughts never mind .... :-)>
On Sat, Dec 12, 2009 at 12:21 PM, bank kus <kus.bank at gmail.com> wrote:
> Is this guaranteed to complete in a finite number of steps. Asking
> because am evaluating if I can implement ticket locking using this.
> On a 16 virtual core system if all 16 vcores simultaneously had
> threads invoke this operation ..
> <a> are all vcores guaranteed to block context switching to any other
> threads on their runqueues until this operation completes
> <b> is there fair arbitration between cores. The pathological case
> being vcore 2 gets to increment then gets to do it again while other
> vcores wait trying to do so.
> I understand this would depend upon the hw instructions used but am
> curious if any fair expectation can be made out of this API.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest