То есть отслеживать лайфтайм мьютекса не выйдет.
Но хотя бы можно не дать использовать данные без залоканного мьютекса.

Семантика вьедается в мозги ппц

я первым делом растовский мьютекс для плюсовой скодобазы заимплементил, сразу стало меньше “забытых” доступов без лока

Добрый день джентельмены, есть такой вопрос, вот пишу веб на актикс-веб, решил сделать DI контейнер вот таким образом

pub struct DI {
    services: HashMap<TypeId, Arc<dyn Any + Send + Sync>>,
    params: HashMap<String, Arc<dyn Any + Send + Sync>>,
}

в него можно положить и достать сервис указав его тип

вопрсо такой, правильно ли я делаю заворачивая всё в Arc? если не заворачивать то DI не передаётся в

App::new()
   .data(di.clone())
задумался на тем какой перформанс кост у этого дела. сервсы у меня в реквест хендлерах вытаскиваются,

context
    .di
    .service::<AuthService>()
    .login(&username, &password)

метод вытаскивания сервиса вот такой

pub fn service<T: 'static + Send + Sync + Dependency>(&self) -> Arc<T> {
    self.services
        .get(&TypeId::of::<T>())
        .unwrap_or_else(|| panic!(format!("No service `{}` found in DI container", T::service_name())))
        .clone()
        .downcast()
        .unwrap()
}

получается это единственное место где у Арка увеличивается его счётчик и как я понимаю он там как то атомарно увеличивается.. это медленнее чем неатомарно и по этому поводу у меня есть некоторое беспокойство.. а как у вас?

> задумался на тем какой перформанс кост у этого дела

сделай бенч, это же так просто:
https://gist.github.com/mexus/4a8fcaff64c4c0bbc1b027770d9aa979

11.5 наносекунд на клон

это засада 😉🤣😂

кстати я раньше это дело не бенчал и думал, что там будет буквально пара наносекунд ))

cpu target native

ничё не меняет :(

хм, странно...

атомарный инкремент счетчика одинаково делается везде вроде как

не не, он немного разный для натив и не натив, в этом и кривизна x86_64

хммм, хочу асм посмотреть