[concurrency-interest] AtomicInteger.getAndIncrement()

bank kus 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
CAS too.

<just random thoughts never mind .... :-)>
banks

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.
>
> Regards
> banks
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



-- 
banks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20091212/0e153c0d/attachment.html>


More information about the Concurrency-interest mailing list