On Sat, Mar 18, 2006 at 05:46:30PM -0500, [EMAIL PROTECTED] wrote:
> B-trees are popular for a similar reason. A node is an obvious unit of
> granularity, since different threads can work in different nodes without
> interfering. Not only is the page size tunable, there is also an obvious
> way t
G'day all.
On Wed, Mar 08, 2006 at 01:50:06PM +0200, Einar Karttunen wrote:
> Does anyone have an efficient tree implemented in STM that
> supports concurrent updates in an efficient fashion?
One could easily rewrite this question as:
Does anyone have an efficient tree that
supports concu
Sorry for the slow reply,On 3/8/06, Einar Karttunen wrote:
Does anyone have an efficient tree implemented in STM thatsupports concurrent updates in an efficient fashion? Thisseems suprisingly hard to implement - a normal binarytree with links as TVar is very slow and does
On 08.03 13:32, Tomasz Zielonka wrote:
> > This seems suprisingly hard to implement - a normal binary tree with
> > links as TVar is very slow and does not scale very well.
>
> By "normal" you mean unbalanced? Do you think it's slow because it's not
> balanced, or because of STM?
Unbalanced in th
On Wed, Mar 08, 2006 at 01:50:06PM +0200, Einar Karttunen wrote:
> Does anyone have an efficient tree implemented in STM that
> supports concurrent updates in an efficient fashion?
Interesting idea!
> This seems suprisingly hard to implement - a normal binary tree with
> links as TVar is very slo
Hello
Does anyone have an efficient tree implemented in STM that
supports concurrent updates in an efficient fashion? This
seems suprisingly hard to implement - a normal binary
tree with links as TVar is very slow and does not scale
very well.
- Einar Karttunen
___