lkml.org 
[lkml]   [2002]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] 2.4.x write barriers (updated for ext3)
Date
From
mason@suse.com said:
> Sorry, what do you mean by multi-threaded back end completion of the
> transaction?

It's an old idea from databases with fine grained row level locking. To alter
data in a single row, you reserve space in the rollback log, take the row
lock, write the transaction description, write the data, undo the transaction
description and release the rollback log space and row lock. These actions
are sequential, but there may be many such transactions going on in the table
simultaneously. The way I've seen a database do this is to set up the actions
as linked threads which are run as part of the completion routine of the
previous thread. Thus, you don't need to wait for the update to complete, you
just kick off the transaction. You are prevented from stepping on your own
transaction because if you want to alter the same row again you have to wait
for the row lock to be released. The row locks are the "barriers" in this
case, but they preserve the concept of transaction independence. Of course,
most DB transactions involve many row locks and you don't even want to get
into what the deadlock detection algorithms look like...

I always imagined a journalled filesystem worked something like this, since
most of the readers/writers will be acting independently there shouldn't be so
much deadlock potential.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.091 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site