Re: computational model of transactions

"David Cressey" <dcressey_at_verizon.net> wrote in message news:wRlBg.1552$Fl2.107_at_trndny01...
>
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> news:1bbBg.1409$1f6.800_at_newssvr27.news.prodigy.net...
>
>> A compiler can tell the difference between x = 10 and x = x + 5, why
>> can't
> a
>> dbms?
>
> Sure a compiler can tell the difference, but a compiler doesn't actually
> perform the operation. It generates code that, when executed, performs
> the
> operation. When the resulting machine code gets executed, the difference
> in
> intent between
> the two operations you state may not be obvious at all.
>

I think I see where you're coming from, but I don't agree. A compiler that produced code that replaces a value when a modification was intended is broken, especially if the code can execute concurrently and shares memory.

At the machine code level, there is a distinct difference between replacement and modification.

For replacement, the instruction is MOV, for modification, there are several instructions, one for each operation, one example is ADD.

Within the CPU circuitry, there may be a read--add--write sequence, but that circuitry also ensures that every instruction is atomic, and in the Intel world, provides additional circuitry to ensure that an instruction can be forced to be atomic in a multiprocessor environment.

> Not so long ago, (perhaps before you were born) the main memory of
> computers was based on cores, little ferrite toruses.
> Reads were ALWAYS destructive in that implementation. Hence core memory
> controllers always operated in a read-pause-write mode.

I know this is off-topic, but I worked on a system that used nondestructive readout core memory. The concept behind it required two cores per bit, and whether or not they represented a one or a zero depended on the difference in the magnitude of the hysteresis loops of the two cores. The benefit was that the state of the memory could survive a power loss even if that loss occurred during a readout.

>... At the level of the
> cores themselves, you would have been hard put to tell the difference
> between three flavors of writes: the replacement and the modification you
> have been discussing, and a third. The third flavor of write is where the
> old value is being rewritten beck to the cores, because the read wiped
> them
> out.
>
> My purpose in writing the above is not to wax lyrical about core memory,
> but
> to broaden your perspective. Just as there are multiple levels of
> interpretation and execution in a compiler, in a CPU and in a memory
> subsystem, so likewise there are multiple client-server levels of
> collaboration between quasi autonomous agents within a database server.
>
> And a database server is only one part of a dbms.
>
>
>
>
>
>
>
>
>
Received on Sun Aug 06 2006 - 18:55:23 CEST