s/Mutex/ceph::mutex/ and Mutex::is_locked_by_me()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



hi Patrick and list,

i am trying replace Mutex with ceph::mutex in Ceph. the goal is to
deprecate and then remove Mutex and Cond from our project. as we have
already ceph::mutex and ceph::condition_variable. it's confusing and,
in the long run, i think, it will hurt us as a technical debt.

most of the refactory work is quite straightforward, and we can always
replace Mutex::is_locked_by_me() with ceph_mutex_is_locked_by_me().
this macro will be expanded to `true` in release build. as we think it
will be used only by `ceph_assert()` and `assert()`.

but i realized that we are also using Mutex::is_locked_by_me() in
functional code which won't be optimised out. for instance, in
MDSRank::MDSRank() we check "mds_lock.is_locked_by_me()", if it's
true, we just `handle_write_error(r)` without acquiring the lock,
otherwise, we will call this function within `mds_lock`. the same
applies to `MDSDaemon::handle_conf_change()`. so i am wondering if
it's okay to change `mds_lock` to a recursive lock, so we don't need
to query this information from
the mutex.

what do you think?


-- 
Regards
Kefu Chai
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx



[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux