Re: race on multi-processor solaris

From: Joe Seigh (jseigh_01_at_xemaps.com)
Date: 12/08/03 

Date: Mon, 08 Dec 2003 21:51:36 GMT

David Schwartz wrote:
>
> "Joe Seigh" <jseigh_01@xemaps.com> wrote in message
> news:3FD471B4.AB06C349@xemaps.com...
>
> > > This is especially bad on the P4. All read-modify-write operations
> > > write, even if they don't have to (like a compare and swap where the
> compare
> > > fails). So if you have 8 CPUs and 7 of them fail to make forward
> progress,
> > > each of the 7 failures requires ugly FSB traffic to unshare and dirty
> the
> > > memory just to write the same value back!
>
> > Except that the instant the cpu holding the lock releases it, all the
> other
> > processors more or less simultaneously attempt to acquire it.
>
> Once per CPU per timeslice. Then the conflicting thread is descheduled
> and doesn't get another chance to cause contention until all other threads
> have run.
>
...
> I'm not sure whether we're talking about lock-free versus spinlocks or
> lock-free versus regular locks. The fundamental benefit of locks is that
> contention is avoided by descheduling contending threads. The fundamantal
> benefit of lock-free algorithms is that threads are not descheduled when
> they contend, they simply run slower.

Spin locks primarily. A suspend type lock effectively slows things down
so the contention level is lower. Though I guess that is one way of dealing
with contention, slow down. If you have adaptive mutexes then they'll behave
more like spin locks if the locks are held for relatively shore durations.

>
> You can really only prefer a lock-free algorithm if you have good reason
> to believe that there won't be any other thread that can run more
> effectively if the thread accessing the collection were descheduled. Though
> the argument may be different on CPUs like Opteron where the FSB scales with
> the number of CPUs.
>
> For many applications, the most important case is where only one thread
> is accessing the collection and other threads would like to do other things.
> In this case, lock-free is a big loser because it requires more atomic
> operations than locks do. (Again, consider adding 12 items to 12 queues.)
>

You keep picking an absurd and unrealistic example to make your case.

Joe Seigh

Relevant Pages

  • Re: race on multi-processor solaris
    ... >> On a linked list with locks, one thread will always be running on ... >> at full speed and there will be zero contention. ... > busy-waiting threads waste an appreciable amount of CPU time. ... rebuttal to "context switches are bad, ...
    (comp.unix.solaris)
  • Re: [PATCH] remove lame schedule in journal inverted_lock (was: Re: [patch 0/3] j_state_lock, j_list
    ... do its business then release the locks. ... > starving the other CPU: this CPU would keep on grabbing the lock. ... This is probably the best for mainline, since, as you mentioned, the ... that the latency of kjournald, even without SCHED_FIFO will be large. ...
    (Linux-Kernel)
  • Re: Locking fundamentals
    ... It's a bad idea to use locks if you can achieve the same thing locklessly, ... Simple statistics are about the only place they're safe to use without very careful thinking. ... They can be used instead of locks when you know your data will only be accessed on one CPU, and you only need to protect it from interrupt handlers. ... they work alright if the thread is dedicated to a single purpose and written entirely with that synchronization model in mind, or if the period of pinning is brief. ...
    (freebsd-hackers)
  • Re: [patch 1/4] x86: FIFO ticket spinlocks
    ... only 2 cores (on the same CPU) could get the ... The other 6 cores on the system were ... the locks also drop the locks and do quite a bit of work before taking ... not mean that the process is letting go of the cacheline. ...
    (Linux-Kernel)
  • Re - lock up- intermittant
    ... Were not sure what "locks up" means. ... If her norton anti-virus is from a legimate ... >this sometime after she reinstalled Norton ... I removed the cpu fan and cleaned and dusted ...
    (microsoft.public.windowsxp.perform_maintain)