Compartilhar via

Usando objetos Thread-Safe

  • Artigo

Aplica-se a: Outlook 2013 | Outlook 2016

Os aplicativos cliente podem assumir que os objetos usados diretamente ou como retornos de chamada são sempre seguros por thread, exceto nos seguintes casos:

  • O objeto status de um provedor de transporte obtido por meio de uma chamada de cliente para IMAPISession::OpenEntry com um identificador de entrada da linha de tabela status do provedor.

  • Todos os objetos de formulário MAPI obtidos por meio de uma chamada de cliente para MAPIOpenFormMgr. Os objetos de formulário obedecem às regras do modelo de apartamento e os clientes devem usá-los e todos os objetos contidos por eles somente no thread que os criou.

Quando um cliente acessa a linha de um provedor de transporte na tabela status que inclui o identificador de entrada do objeto status associado, o cliente pode chamar OpenEntry com esse identificador de entrada para abrir o objeto status. Esse objeto status não é thread-safe porque os provedores de transporte são executados no contexto do spooler MAPI e não mantêm um contexto separado para seu objeto status. O objeto status obedece às regras do modelo de apartamento e os clientes devem usá-lo apenas no thread que o criou.

Um cliente também deve invocar MAPIInitialize em cada thread antes de usar quaisquer objetos MAPI e MAPIUninitialize quando esse uso estiver concluído. Essas chamadas devem ser feitas mesmo se os objetos a serem usados forem passados para o thread de uma origem externa. MAPIInitialize e MAPIUninitialize podem ser chamados de qualquer lugar, exceto de dentro de uma função DllMain win32, uma função que é invocada pelo sistema quando processos e threads são inicializados e encerrados, ou em chamadas para as funções LoadLibrary e FreeLibrary .

Os objetos de uso indireto nunca devem ser considerados thread-safe. Os objetos de uso indireto são retornados por métodos que exigem ponteiros de interface de destino como parâmetros de entrada. Exemplos desses métodos são IMAPIProp::CopyTo e CopyProps, IMAPIFolder::CopyFolder e CopyMessage e IMsgServiceAdmin::CopyMsgService. Se um provedor de serviços quiser chamar esse objeto de um thread diferente do que foi passado, o provedor será responsável por empacotar explicitamente o objeto.