Re: [HACKERS] Concurrent free-lock

2005-01-27 Thread Hannu Krosing
Ühel kenal päeval (kolmapäev, 26. jaanuar 2005, 13:30+1100), kirjutas Neil Conway: > Simon Riggs wrote: > > The one factor which stands out for me from this is that Keir Fraser's > > and Tim Harris' algorithms are available as *code*, which additionally > > are covered by a licence which appears to

Re: [HACKERS] Concurrent free-lock

2005-01-26 Thread Pailloncy Jean-Gerard
This is a very important thread. Many thanks to Jean-Gerard for bringing the community's attention to this. Thanks Simon. I was working during my PhD on some parallel algorithm. The computer was a 32-grid processor in 1995. In this architecture we need to do the lock on the data, with minimum co

Re: [HACKERS] Concurrent free-lock

2005-01-25 Thread Simon Riggs
On Wed, 2005-01-26 at 13:30 +1100, Neil Conway wrote: > Simon Riggs wrote: > > The one factor which stands out for me from this is that Keir Fraser's > > and Tim Harris' algorithms are available as *code*, which additionally > > are covered by a licence which appears to be an MIT/BSD variant licenc

Re: [HACKERS] Concurrent free-lock

2005-01-25 Thread Neil Conway
Simon Riggs wrote: The one factor which stands out for me from this is that Keir Fraser's and Tim Harris' algorithms are available as *code*, which additionally are covered by a licence which appears to be an MIT/BSD variant licence. If you're referring to their "Lock-free library", that is license

Re: [HACKERS] Concurrent free-lock

2005-01-25 Thread Jonah H. Harris
Simon, You are correct. My negative experience with lock-free data structures has been due to the different implementations I've tried. The theory sounds good and no doubt, a good implementation could very likely be developed with some time. I'm in no way against using lock-free data structu

Re: [HACKERS] Concurrent free-lock

2005-01-25 Thread Simon Riggs
On Tue, 2005-01-25 at 13:59 +1100, Neil Conway wrote: > On Mon, 2005-01-24 at 19:36 -0600, Min Xu (Hsu) wrote: > > In any case, I think only when contention is high the non-blocking > > algorithms are worth looking at. So can someone shine some light > > on where the contention might be? > > The m

Re: [HACKERS] Concurrent free-lock

2005-01-25 Thread Pailloncy Jean-Gerard
Here is some pretty good info on lock-free structures... I'm pretty sure I tested their code in a multithreaded high-concurrency environment and experienced the problems I was discussing. I understand. The algorithm is quite complex. The old version was not really fast. In the paper cited, some t

Re: [HACKERS] Concurrent free-lock

2005-01-24 Thread Min Xu (Hsu)
On Tue, 25 Jan 2005 Neil Conway wrote : > Amazingly, there *are* lock-free hash table > algorithms (e.g. [1]), but at first glance they seem pretty complex, and It is a little scary when I read the lock-free hash table algorithm needs a theorem prover to prove its correctness. I'd guess maintainin

Re: [HACKERS] Concurrent free-lock

2005-01-24 Thread Neil Conway
On Mon, 2005-01-24 at 19:36 -0600, Min Xu (Hsu) wrote: > In any case, I think only when contention is high the non-blocking > algorithms are worth looking at. So can someone shine some light > on where the contention might be? The major point of contention that has been identified in the past is o

Re: [HACKERS] Concurrent free-lock

2005-01-24 Thread Min Xu (Hsu)
Neil and others, It might be interesting to look at some of the papers by Michael Scott et al. I am not an expert on non-blocking data structures, but the following page seems interesting: http://www.cs.rochester.edu/u/scott/synchronization/ esp. "(7) nonblocking "dual" data structures, which co

Re: [HACKERS] Concurrent free-lock

2005-01-24 Thread Neil Conway
On Mon, 2005-01-24 at 16:50 -0700, Jonah H. Harris wrote: > Here is some pretty good info on lock-free structures... I'm pretty sure > I tested their code in a multithreaded high-concurrency environment and > experienced the problems I was discussing. Fair enough, but my hope would be that those

Re: [HACKERS] Concurrent free-lock

2005-01-24 Thread Jonah H. Harris
Neil, Here is some pretty good info on lock-free structures... I'm pretty sure I tested their code in a multithreaded high-concurrency environment and experienced the problems I was discussing. http://www.cl.cam.ac.uk/Research/SRG/netos/lock-free/ Neil Conway wrote: On Mon, 2005-01-24 at 08:35 -

Re: [HACKERS] Concurrent free-lock

2005-01-24 Thread Neil Conway
On Mon, 2005-01-24 at 08:35 -0700, Jonah H. Harris wrote: > Lock free data structures are cool... but not really applicable to > databases. They have a high maintenance overhead, severe complexity, > and will fail when there are many concurrent inserts/deletes to the > structure. Can you elabo

Re: [HACKERS] Concurrent free-lock

2005-01-24 Thread Jonah H. Harris
Lock free data structures are cool... but not really applicable to databases. They have a high maintenance overhead, severe complexity, and will fail when there are many concurrent inserts/deletes to the structure. I messed with them a year or so ago, and that's what I found in every implemen

[HACKERS] Concurrent free-lock

2005-01-24 Thread Pailloncy Jean-Gerard
Hi, I read recently a paper Keir Fraser & Tim Harris, Concurrent Programing without Locks, ACM Journal Name, vol V, n° N, M 20YY, Page 1-48 About algorithm to manage structure (exemple about red-black tree, skip list) with dead-lock free property, parallel read, etc. Does this have been studied