Question about composability of locks
YUAN, Nan
example" deleting Item X of Table A and inserting X into Table B
cannot be combined as one single atomic operations using locks" in
some wiki, but I don't understand.
Joe Seigh
Composability is about the composability of operations which
is problemantic when locking is involved since locks can have
deadlocking issues.
The "example" as stated is incorrect since you can easily
make them atomic with a third lock that is acquired before
acquiring either of the table locks.
You're entering the realm of multi-threaded compoable functional
programming and transactional memory where the hype and bs are so
dense so as to qualify as a new form of matter.
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software.
YUAN, Nan
>
> Composability is about the composability of operations which
> is problemantic when locking is involved since locks can have
> deadlocking issues.
>
> The "example" as stated is incorrect since you can easily
> make them atomic with a third lock that is acquired before
> acquiring either of the table locks.
>
> You're entering the realm of multi-threaded compoable functional
> programming and transactional memory where the hype and bs are so
> dense so as to qualify as a new form of matter.
>
> --
> Joe Seigh
>
> When you get lemons, you make lemonade.
> When you get hardware, you make software.
Many descriptions I've read say that "lock is not composable because
of deadlock issue", however, I don't truly understand the issue
because I can't construct or find some proper example. Can you give me
one please if it's convenient?
Chris Thomasson
news:1180400733.6...@j4g2000prf.googlegroups.com...
[...]
You can experience the "negative" effects of non-composeability wrt locking
when you execute a "callback" function while you holding lock(s)... The
callback would be executing unknown code perhaps... user code... user code
which may decide to lock something else... Getting the locking order screwed
up. Basic locking errors...
You can get composeable lock when you learn how to use them without
deadlocking. Please note that this ability is nothing special. Its doable,
and practical.
TM is nothing more than opiate-like pain-killers that are strong enough to
make sure you don't notice your mistakes. The TM will "do it for you"... Of
course you will be doped up during the entire process!
:^0
http://groups.google.com/group/comp.arch/browse_frm/thread/91cb3fbfa2eb362a
[...]
Joe Seigh
> On 5月26日, 下午8时09分, Joe Seigh <jseigh...@xemaps.com> wrote:
>
>>Composability is about the composability of operations which
>>is problemantic when locking is involved since locks can have
>>deadlocking issues.
>>
>>The "example" as stated is incorrect since you can easily
>>make them atomic with a third lock that is acquired before
>>acquiring either of the table locks.
>>
>>You're entering the realm of multi-threaded compoable functional
>>programming and transactional memory where the hype and bs are so
>>dense so as to qualify as a new form of matter.
>>
> Many descriptions I've read say that "lock is not composable because
> of deadlock issue", however, I don't truly understand the issue
> because I can't construct or find some proper example. Can you give me
> one please if it's convenient?
>
Deadlock can occur if threads try to acquire locks in different orders, e.g.
thread 1 holds lock A and trys to acquire lock B, and thread 2 holds lock B
and trys to acquire lock A.
This could arise because the code explicitly gets the first locks and then
calls some function which unknown to it tries to acquire the second lock.
It's problematic from a system maintenace point of view. You have to document
a lock hierarchy and document the locking requirements of all the code including
all the code that code calls.
So synchronization without such requirements looks attractive.
There are 2 problems though. One, it's not clear transactional memory
will scale. Secondly, the two operations in the probem would not be
atomic w.r.t. each other without using a common synchronization contruct.