maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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