1 of 1 people found this helpful
Hi Ohn,Have you seen this discussion?Yes, you are correct. Remember that the RCCE allocator works with cache line granularity, so even if we use only a single bit or byte flag, we have to allocate an entire cache line. Regarding 4), I think this is a necessary restriction because the bit twiddling part requires mutual exclusion, but there is only a very limited number of locks to choose from.
Thanks for your answer Andreas!
Yes I read it a couple of times but still the bottom line is not 100% clear to me..
Still regarding 3) and 4) :
Assuming SINGLEBITFLAGS=0 and we allocated 32 flags in a single cache line.
Can core X and core Y write to flag A and flag B at the same time without any problems?
Can you please explain in simple words how it is being done?
Why bit twiddling, when SINGLEBITFLAGS=0, is different from when SINGLEBITFLAGS=1?
If we can twiddle 8-bits in the first case without locking the cache line, then we can twiddle 8-bits in the second case without locking it. No? (and thus lock only 8 flags instead of 256 flags)
Yes, there is no problem with writing single bytes (see RCCE_put_char in RCCE_put.c). The only difficulty here is that MPB writes within a cache line are being accumulated in the write combine buffer, and we have to make sure that the data is actually flushed to the MPB and doesn't just sit in the buffer until some time in the future. I remember there was an interesting discussion about this topic... Here it is:
There is no bit twiddling in the case of byte flags! You just write a '1' to set the flag and a '0' to unset it, that's it. But for bit flags, you have to copy the corresponding byte into private memory, change the flag bit, and copy the byte back to the target MPB. And that sequence, instead of doing a single write, requires locking.
It is very clear now...