documentation on nested transactions (DSTM Java code)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

documentation on nested transactions (DSTM Java code)

Kenworthy, John C
I am reading the STM for Dynamic-Sized Data Structures paper.   I am
interested in nested transactions.  A footnote in this paper indicated
that they are handled in a "rudimentary form".  However, looking at the
code package I have (Java DSTM pkg), it looks like any ability to nest
has been locked out by the logic checks for 'nesting depth'.  

If anyone knows more about the nesting depth implementation, I would
like to hear about it.  Or, better yet, if you have a source you can
point me to that documents some discussion about this, that would be
excellent.  

Thx,
jc

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Dawid
Kurzyniec
Sent: Friday, December 02, 2005 2:32 PM
To: David Holmes
Cc: [hidden email]
Subject: Re: [concurrency-interest] when to use lock and
whentouselockInterruptibly


>>With a lock() you always get the lock? What if the thread is
>>interrupted while it wants to acquire a lock with the lock() method.
>>What is going to happen? With a lockInterruptibly() a
InterruptedException is thrown.
>>But what happens with a normal lock() method?
>>    
>>
>
>As Dawid said the normal lock() method will only return once the lock
>has been acquired, and it always returns normally. If you get
>interrupted while trying to acquire it then you remain with your
interrupt state set.
>
>David Holmes
>
>  
>
A small clarification: when I wrote my answer, I (and David, I guess)
had in mind ReentrantLock and ReentrantReadWriteLock. For user-defined
locks, the documentation actually allows lock() method to throw
unchecked exception (e.g. as a deadlock-avoidance measure). Also,
theoretically, lock() can throw OutOfMemoryError even from
ReentrantLock.lock (right?) so it is not 100% accurate to say that
lock() can never complete abruptly.

It has nothing to do with interruption, though - the lock() method is
supposed to block *non-interruptibly* if the lock is not immediately
available. I imagine it is possible to write a lock implementation that
would violate this and instead throw an unchecked exception upon
interruption of lock(), but in my understanding of the API, such
implementation would be broken - because the javadoc only allows such
exception to be thrown when an *erroneous* use of the lock is detected.

So, to sum up: for properly written lock classes (ReentrantLock in
particular), lock() is non-interruptible and, for all practical
purposes, cannot complete abruptly, unless really bad things happen from
which you probably should not try to recover.

Regards,
Dawid

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

re: documentation on nested transactions (DSTM Java code)

Mark Moir


> Message: 2
> Date: Sat, 03 Dec 2005 20:18:08 -0700
> From: "Kenworthy, John C" <[hidden email]>
> Subject: [concurrency-interest] documentation on nested transactions
> (DSTM Java code)
> To: [hidden email]
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
> I am reading the STM for Dynamic-Sized Data Structures paper.   I am
> interested in nested transactions.  A footnote in this paper indicated
> that they are handled in a "rudimentary form".  However, looking at the
> code package I have (Java DSTM pkg), it looks like any ability to nest
> has been locked out by the logic checks for 'nesting depth'.  

The "rudimentary form of nesting" we referred to in the paper is just
"flattening", i.e., nested transactions become part of the outermost
transaction.  This is implemented with a simple nesting depth counter.
Our paper and code release were intended to demonstrate the key ideas
underlying DSTM, so we resisted the temptation to include many bells and
even a few whistles, and this included more sophisticated forms of nesting.

Cheers

Mark
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest