Início / coding / Perguntas / 76985152
Accepted
ofo
Asked: 2023-08-27 07:05:38 +0800 CST

É seguro usar RefCell em uma estrutura de dados acessada com algum bloqueio de granulação grossa?

  • 772

Estou escrevendo um código assíncrono do Tokio. Eu tenho uma estrutura de dados de vários índices que mantém os usuários onde desejo protegê-los com um bloqueio de granulação grossa (ao contrário do bloqueio por objeto). Eu tenho algo assim:

use tokio::sync::RwLock;

struct User {
  id: u64,
  name: String,
}

// This class is not thread-safe.
struct UserDb {
  by_id: HashMap<u64, Arc<RefCell<User>>>,
  by_name: HashMap<String, Arc<RefCell<User>>>,
}

impl UserDb {
  pub fn add_user(&mut self, name: String) -> Result<(), Error> {
    // ...
  }
}

// This class is thread-safe.
struct AsyncDb {
  users: RwLock<UserDb>,
}

impl AsyncDb {
  pub async fn add_user(&self, name: String) -> Result<(), Error> {
    self.users.write().await.add_user(name)
  }
}

// QUESTION: Are these safe?
unsafe impl Send for AsyncDb {}
unsafe impl Sync for AsyncDb {}

Sem características Sende Syncno final, o compilador reclama que RefCell<User>não é Sende Sync(razoavelmente) e, portanto, não é seguro para acessar/modificar por meio de AsyncDb::add_user.

Minha solução foi implementar Sende Syncpara a estrutura de dados, uma vez que há um bloqueio de granulação grossa em AsyncDbtorno de UserDb, que contém os referidos RefCells.

Esta é uma solução correta? Isso viola algum invariante? Existe uma maneira melhor de lidar com isso?

Nota: Rust iniciante aqui. Provavelmente tenho muitas lacunas conceituais, então, por favor, informe-as se as coisas não fizerem sentido.

asynchronous

2 respostas

  1. Best Answer

    É quase certo que isso não é correto, a menos que você use apenas bloqueios de gravação, mesmo ao ler os usuários.

    As RefCell::borrow*()funções não são thread-safe porque não mantêm a contagem interna atomicamente. Isso significa que usar borrow()para ler de um RefCell<User>quando protegido apenas por um bloqueio de leitura não é adequado.

    Se você já comprou esse design específico, recomendo fortemente substituí-lo RwLockpor um Mutex, pois os bloqueios de leitura serão quase completamente inúteis.

    Substituir RwLockpor Mutexfará com que seu tipo seja implementado automaticamente Sync, mas ainda assim não será implementado Send. Se você mantiver o seu unsafe impl Sendneste caso, precisará ter muito cuidado com o Arcs. Você nunca deve:

    • Retorne uma Arc<RefCell<User>>ou uma referência a um diretamente ou incorporada em outro valor, pois isso permitirá ao chamador clonar o seu próprio valor Arc, que poderá usar para manipular RefCellsem manter um bloqueio.
    • Envie uma Arc<RefCell<User>>referência ou para outro thread/tarefa via thread::spawn(), tokio::spawn(), tokio::spawn_blocking(), enviando um em um canal e assim por diante.
    • 4

  2. Esta estrutura não é segura. RefCellnão pode ser usado em dois threads simultaneamente (ou seja, não implementa Sync) e sua estrutura não está protegendo contra isso.

    Como você usa a RwLock, isso significa que você pode fornecer a vários leitores acesso imutável ao valor de diferentes threads, o que não é permitido. Mas mesmo que você o altere para Mutexexclusivo, você Arcpermite que a propriedade escape da guarda do mutex e preserve o acesso imutável em outro thread, independentemente.

    Dito isto, implementar Sendand provavelmenteSync é válido se você garantir que nenhum escape da proteção do . Porém, se você fizer isso, provavelmente poderá até mesmo rebaixá-los para s. E sim, teria que ser e não porque, novamente, você não pode acessar a partir de vários threads ao mesmo tempo, mesmo de forma imutável.ArcMutexRcMutexRwLockRefCell

    • 2

relate perguntas