Проверить дескриптор указателя действителен

Я хочу реализовать библиотеку Microsoft CryptographicServiceProvider, и в настоящее время я думаю о том, как лучше всего работать с дескриптором контекста, который я создаю.

Мой вопрос специфичен для этого случая, но подход к проектированию можно использовать и в других ситуациях.

Я пришел из управляемого кода, и я не уверен на 100% в отношении многопоточной обработки указателей в C/C++.

Как правило, за создание и уничтожение дескриптора отвечают две функции (CryptAcquireContext, CryptReleaseContext), и все последующие функции CSP используют дескриптор, возвращаемый функцией-создателем.

Я не нашел какой-либо конкретной информации или спецификации от Microsoft, которая бы давала подход к проектированию или правила, как это сделать. Но я провел исследование с другими поставщиками CSP, созданными Microsoft, чтобы выяснить правила проектирования, а именно:

• Функции должны быть потокобезопасными
• Дескриптор контекста не будет использоваться совместно между потоками.
• Если дескриптор контекста недействителен, возврат с ошибкой

Другой поставщик MS CSP вернет действительный указатель в качестве дескриптора или NULL, если нет.

Я не думаю, что вызывающее приложение будет передавать полный мусор, но может случиться так, что оно передаст дескриптор, который уже был освобожден, и моя библиотека должна вернуться с ошибкой.

Это привело меня к трем идеям, как это реализовать:

1. Просто выделите память моей контекстной структуры с помощью malloc или new и верните необработанный указатель в качестве дескриптора.

   Я могу ожидать, что приложения, которые вызывают мою библиотеку, передают действительный дескриптор. Но если нет, моя библиотека столкнется с неопределенным поведением. Поэтому мне нужно лучшее решение.

2. Добавьте указатель, который я создаю, в список (std::list, std::map). Поэтому я могу перебрать список, чтобы проверить, существует ли указатель. Доступ к списку охраняется мьютексом.

   Это должно быть безопасно, и регулярное использование API не должно сказываться на производительности. Но в сценарии с сервером терминалов это может быть. В этом случае процесс Windows lsass.exe создает для каждого пользователя, который хочет войти в контекст CSP, отдельный поток и делает около 10 вызовов API для каждого контекста.

   Цель проекта состоит в том, чтобы моя библиотека могла параллельно обрабатывать 300 клиентов. Я не знаю, сколько потоков создано Windows в этом случае.

   Поэтому, если возможно, я бы предпочел реализацию без блокировки.

3. Я выделяю базовую структуру, которая содержит контрольное значение и указатель фактических данных. Используйте указатель этой структуры в качестве дескриптора контекста.

   typedef struct CSPHandle  
   {  
       int Type; // (eg. magic number CSPContext=0xA1B2C3D4)  
       CSPContextPtr pCSPContext;  
   };
   

   Таким образом, я мог прочитать первый байт переданного указателя и проверить, соответствуют ли данные моему определенному типу. И у меня есть полный контроль над фактическим указателем данных, который устанавливается в NULL, если контекст освобождается. Это хорошая или плохая идея?

Что вы думаете об этом случае? Должен ли я использовать один из этих подходов или есть другое решение?

Спасибо