I was thinking after I submitted my previous solution that I should consider all element in reduction object which do not have minimum support count. So, I changed my candidate set with size 2. There were 13 element in my last submission but now there are 21 element. Please check attached file and I hope my reasoning is correct. If it is wrong then let me know.

p0941 wrote:

My solution is different only on fixed-locking and cache-sensitive locking.

For fixed-lock,for example on size 2 ck, 8*4+21*4=116(bytes).

For cache-sensitive locking, 64-4=60, 84/60=1.4 so 2 cache blocks.

84+8=92(bytes)

Well, I believe that Fixed Locking has some fixed number of locks, which is 8 in our case. I have taken 1 lock as per paper. I made mistake there.  There is one equation on paper that if I take only one lock for Fixed Locking scheme then memory requirement is (1 + 1/r) * S. I guess that you have 8 locks that means 8 * 4 = 32 bytes, and you have 21 reduction elements So, 21 * 4 = 84. You have total 116. It is straight forward for Cache-Sensitive locking too. 21 * 4 = 84 and 2 * 4 = 8 for 2 locks. So, Total is 84 + 8 = 92. I think Wen-Han is right on that. 

1. In Ck with Size 1, we have 7 Reduction Element in one Reduction Object;

Fixed Locking = (8*4) + (7*4) = 32 + 28 = 60 Bytes

Cache-Sensitive Locking = (1*4) + (7*4) = 4 + 28 = 32 Bytes

2. In Ck with Size 2, we have 21 Reduction Element in one Reduction Object;

Fixed Locking = (8*4) + (21*4) = 32 + 84 = 116 Bytes

Cache-Sensitive Locking = (2*4) + (21*4) = 8 + 84 = 92 Bytes

3. In Ck with Size 3, we have 9 Reduction Element in one Reduction Object:

Fixed Locking = (8*4) + (9*4) = 32 + 36 = 68 Bytes

Cache-Sensitive Locking = (1*4) + (9*4) = 4 + 36 = 40 Bytes

4. In Ck with Size 4, we have 2 Reduction Element in one Reduction Object:

Fixed Locking = (8*4) + (2*4) = 32 + 8 = 40 Bytes

Cache-Sensitive Locking = (1*4) + (2*4) = 4 + 8 = 12 Bytes

hsankav wrote:

Gaurang,

The support count of P3,P5 is 2  coould you pls check.

Hello hsankav,

I get all candidate sets from Yuri's solution. I checked and (P3, P5) is in T1 and T5. So, Support Count of (P3, P5) should be 2. But, I believe that it does not effect memory requirement of that Reduction Element.

I was going through paper again today and I am little bit confused that do we need to consider Reduction Element and it's support count in different blocks or in one block?

p0941 wrote:

p0941 wrote:

My solution is different only on fixed-locking and cache-sensitive locking.

For fixed-lock,for example on size 2 ck, 8*4+21*4=116(bytes).

For cache-sensitive locking, 64-4=60, 84/60=1.4 so 2 cache blocks.

84+8=92(bytes)

 

One update on full replication:

For example on size-2 CKs, it should be (to my understanding):

21*4*8= 672(bytes) (there is one thread for each transaction)

I feel that if you have 21 reduction element in candidate set with size 2 then your memory requirement is 21 * 4 = 84. Now, You replicate 84 byte of memory with number of processors you have. I have assumed that we have 4 processors (threads). So, 84 * 4 = 336 Byte. I don't think that we have threads for each transactions. Let me know if I am misunderstanding something...

p0941 wrote:

jadiagaurang wrote:

p0941 wrote:

p0941 wrote:

My solution is different only on fixed-locking and cache-sensitive locking.

For fixed-lock,for example on size 2 ck, 8*4+21*4=116(bytes).

For cache-sensitive locking, 64-4=60, 84/60=1.4 so 2 cache blocks.

84+8=92(bytes)

 

One update on full replication:

For example on size-2 CKs, it should be (to my understanding):

21*4*8= 672(bytes) (there is one thread for each transaction)

I feel that if you have 21 reduction element in candidate set with size 2 then your memory requirement is 21 * 4 = 84. Now, You replicate 84 byte of memory with number of thread you have. I have assumed that we have 4 processors (threads). So, 84 * 4 = 336 Byte. I don't think that we have threads for each transactions. Let me know if I am misunderstanding something...

Since each processor can deal with one transaction or one set of transactions, and there could be many threads in one processor.  The paper reads that a reduction object is replicated for each thread, not each processor.  That's how I got the result.  So the essential question is, can we treat a processor equivalent to a thread? My answer is no.

And, when one processor has a set of transaction, one copy of reductin object for one processor won't be enough.

p0941 wrote:

p0941 wrote:

jadiagaurang wrote:

p0941 wrote:

p0941 wrote:

My solution is different only on fixed-locking and cache-sensitive locking.

For fixed-lock,for example on size 2 ck, 8*4+21*4=116(bytes).

For cache-sensitive locking, 64-4=60, 84/60=1.4 so 2 cache blocks.

84+8=92(bytes)

 

One update on full replication:

For example on size-2 CKs, it should be (to my understanding):

21*4*8= 672(bytes) (there is one thread for each transaction)

I feel that if you have 21 reduction element in candidate set with size 2 then your memory requirement is 21 * 4 = 84. Now, You replicate 84 byte of memory with number of thread you have. I have assumed that we have 4 processors (threads). So, 84 * 4 = 336 Byte. I don't think that we have threads for each transactions. Let me know if I am misunderstanding something...

Since each processor can deal with one transaction or one set of transactions, and there could be many threads in one processor.  The paper reads that a reduction object is replicated for each thread, not each processor.  That's how I got the result.  So the essential question is, can we treat a processor equivalent to a thread? My answer is no.

And, when one processor has a set of transaction, one copy of reductin object for one processor won't be enough.

As I said, the assumption is one thread per processor, so one reduction object for each thread/processor.