Re: Lock-free databases
Date: Wed, 09 Nov 2005 12:20:37 -0500
> Joe Seigh wrote:
>>vc wrote: >>> >>>Since they "haven't provided any facts significant to anyone familiar >>>with lock-free programming techniques", how can you claim that " >>>Lock-free techniques similar to the ones covered by their patents have >>>be used in operating system kernels for decades and those operating >>>systems weren't going around proclaiming they were lock-free". >>> >> >>Because I used to be a mainframe kernel developer and implemented >>some of those lock-free algorithms. In fact I did an RCU implementation >>in the mid 80's.
> 1. How does your being familiar with some lock-free algorithms and
> having implemented others let you *know* what specific lock-free
> algorithms ANTs uses (unless you familiar with the patents in question
> in which case there is a contradiction with your other statement that
> they "haven't provided any facts significant to anyone familiar with
> lock-free programming techniques") ?
They haven't quantified the performance contribution of the patents
and knowing the techniques in question, they'd have to have some
very specific performance bottlenecks to get a significant benefit.
> 2. For my own education, while I am aware that IBM/370 had the compare
> and swap instruction (as well as 'test and set') , what specific
> lock-free algorithms, other than multiprocessing support, were
> implemented in the mainframe kernel 20-30 years ago ?
Lock-free LIFO queues and lock-free enqueuing onto FIFO queues. Some fast pathed things like WAIT/POST bypass. Examples of those were in appendix A for the 370/390/z-Arch Principles of Operation. And an RCU like mechanism in the VM operating system. Those would be the main ones that I can think of offhand.
-- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software.Received on Wed Nov 09 2005 - 18:20:37 CET