Temos a necessidade de vários programas para chamar funções em uma biblioteca comum. As funções da biblioteca acessam e atualizam uma memória global comum. As chamadas de função de cada programa precisam ver essa memória global comum. Essa é uma chamada de função precisa ver as atualizações de qualquer chamada de função anterior, mesmo se chamado de outro programa. Por razões de compatibilidade, temos várias restrições de design sobre como as funções expostas pela biblioteca compartilhada devem operar:

Quaisquer itens de dados (tipos de dados padrão e objetos) declarados globalmente devem estar visíveis para todos os chamadores, independentemente do encadeamento no qual o código está sendo executado.Quaisquer itens de dados declarados localmente em uma função são visíveis apenas dentro dessa função.Qualquer tipo de dados padrão ou uma instância de qualquer classe pode aparecer localmente ou globalmente ou em ambos.

Uma solução é colocar a memória global comum da biblioteca na memória compartilhada nomeada. A primeira chamada de biblioteca criaria a memória compartilhada nomeada e a inicializaria. Chamadas de programa subseqüentes obteriam o endereço da memória compartilhada e o usariam como um ponteiro para a estrutura de dados global. As instâncias de objetos declaradas globalmente precisariam ser alocadas dinamicamente na memória compartilhada, enquanto as instâncias de objetos declaradas localmente poderiam ser colocadas na pilha ou no heap local do encadeamento do chamador. Os problemas surgem porque os objetos inicializados na memória global podem criar e apontar para sub-objetos que alocam (nova) memória adicional. Essas novas alocações também precisam estar na memória compartilhada e serem vistas por todos os chamadores da biblioteca. Outra complicação é que esses objetos, que contêm strings, arquivos, etc., também podem ser usados ​​no programa de chamada. Quando declarada no programa de chamada, a memória do objeto é local para o programa de chamada, não compartilhada. Então, o código do objeto precisa lidar com qualquer caso. Parece-nos que a solução exigirá que substituamos os operadores new, regular new e delete da colocação global. Encontramos um design para um sistema de gerenciamento de memória que parece funcionar, mas não encontramos nenhuma implementação real. Se alguém souber de uma implementação do design de gerenciamento de memória de Nathan Myers (http://www.cantrip.org/wave12.html?seenIEPage=1) Eu apreciaria um link para ele. Alternativamente, se alguém souber de outro gerenciador de memória compartilhada que acomode dinamicamente a alocação de objetos, eu também adoraria conhecê-lo. Eu verifiquei as bibliotecas Boost e todas as outras fontes que posso encontrar, mas nada parece fazer o que precisamos. Nós preferimos não ter que nos escrever. Como o desempenho e a robustez são importantes, seria bom usar código comprovado. Agradecemos antecipadamente por quaisquer ideias / ajuda.

Obrigado pelas sugestões sobre as bibliotecas ATL e OSSP. Eu estou verificando-os agora, embora eu esteja com medo de que o ATL seja muito Wincentric se o alvo for Unix.

Uma outra coisa agora parece clara para nós. Como os objetos podem ser criados dinamicamente durante a execução, o esquema de gerenciamento de memória deve poder alocar páginas adicionais de memória compartilhada. Isso agora está começando a parecer um gerenciador de memória de substituição de heap completo.