 |
|
| Linux Forum Index » Linux Development - System » thread memory size... |
|
Page 4 of 4 Goto page Previous 1, 2, 3, 4 |
|
| Author |
Message |
| David Schwartz... |
 Posted: Tue Oct 13, 2009 10:25 am |
|
|
|
Guest
|
On Oct 13, 3:43 am, Jan Helgesen <s... at (no spam) nospam.com> wrote:
Quote: So what you are also saying here is that with a lock, when the A1 is
running and A2 is blocked, A2 will not be scheduled and that frees up
the other core so that B1 or B2 can run instead, right?
Exactly.
Quote: In other words all those threads that can't really do any real work,
will waste cpu cycles when based on a lock-free algorithm, because the
only thing they will do is spin-wait on different cores until the lock
is released and the try to acquire the lock, agreed?
No, lock-free algorithms don't spin-wait on locks. The problem is that
accesses to shared resources drop to FSB speed (or its equivalent,
depending on CPU architecture) when there is contention.
Quote: A question would then be, if there are 100 threads waiting for that
resource, even if all threads are running on the same core, they will
have to wait one after another to acquire the lock right?
So as there are more threads the threads will have to wait longer to get
access, right?
It depends on the lock architecture and what else the system as a
whole can do.
Quote: But inappropriate use of a lock-free algorithm simply allows the
threads to continue contending when that contention is avoidable.
You mean its avoidable by using a software based lock instead, right?
(Since we are talking about complex operations)
I'm not sure what you mean by a software-based lock. It's avoidable by
blocking threads that contend so that threads that don't contend can
run instead. Lock-free algorithms do not block threads that contend,
which is good if there's no other thread that can run instead but bad
if there is.
DS |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Fri Nov 27, 2009 6:03 am
|
|