Hi, Sergey! On Nov 28, Sergey Vojtovich wrote:
Eh, that's what I was afraid of. Not seeing elements that were added at about the same time should always be acceptable. Can't it miss elements that were in the list before iteration started (because it has moved to a different location)? The latter is unacceptable in many cases.
No, in this hash implementation elements are never moved in the list. It's prety difficult to move elements lock-free, that's why it wasn't easy to create a good performing lock-free hash. And this one works around this problem by not moving elements at all.
But let's see: - print_cached_tables() - old debug stuff, remove it? - I_S.OPEN_TABLES - seeing elements twice is not good, use PFS?
Duplicates can be removed on the upper layer. Like, I_S data are inserted into a temp table anyway, so a UNIQUE key would solve the issue of duplicates. Or a Unique object.
- close_cached_tables() - seeing elements twice is not a problem. - close_cached_connection_tables() - seeing elements twice is not a problem. - tc_purge() - seeing elements twice is not a problem. - tc_add_table() - seeing elements twice is not a problem. - mdl_iterate() - seeing elements twice is not good, use PFS?
mdl_iterate() - is it for metadata_lock_info plugin? Same answer then.
What about this: sizeof(mysql_rwlock_t)= 64 (just rough estimation) sizeof(pad[128 - sizeof(mysql_rwlock_t)])= 64
It gives: +---------------+---------------+-------------+---------------+---------------+ | rw_lock_t 32b | rw_lock_t 32b | padding 64b | rw_lock_t 32b | rw_lock_t 32b | +---------------+---------------+-------------+---------------+---------------+ Cache line 128b | Cache line 128b |Cache line 128b ----------------+---------------------------------------------+----------------
Okay, indeed. You're right. Regards, Sergei