Hi Massimiliano,

If the locks need to be shared across processes, use a Mutex (the
mutexes can be named for separate processes, or the mutex can be
unnamed if Object Handle Inheritance is used (a flag to CreateProcess,
which is similar to fork(2))).

Otherwise, use a CRITICAL_SECTION. The critical section is more
efficient when only threads of a single process will access shared
data. The efficiency comes from a user land spin, which side steps the
kernel transition if possible. If the spin fails, the thread will have
to transition (the CRITICAL_SECTION is *really* backed by an Event
Object).

Critical sections have the added benefit that you don't have to supply
a SECURITY_ATTRIBUTES. Mutexes take a SECURITY_ATTRIBUTES, which many
folks leave unspecified (NULL) so the net effect is "Everyone, Full
Control". Code which uses a NULL SECURITY_ATTRIBUTES *should* fail a
security audit.

In Windows, both a Mutex and CRITICAL_SECTION are re-entrant by the
owning thread. Also, Condition Variables were recently introduced, so
they are not available on Windows 200, XP, or Server 2003.

Below are some MSDN resources and the boiler plated code I use to grab
a lock. Its not OpenSSL call back specific,

Jeff

"About Synchronization":
http://msdn.microsoft.com/en-us/library/ms681924%28v=VS.85%29.aspx
"Mutex Objects":
http://msdn.microsoft.com/en-us/library/ms684266%28v=VS.85%29.aspx
"Critical Section Objects":
http://msdn.microsoft.com/en-us/library/ms682530%28VS.85%29.aspx

CRITICAL_SECTION cs;
InitializeCriticalSection(&cs);

BOOL AcquireLock()
{
    EnterCriticalSection(&cs);
    return TRUE;
}

BOOL ReleaseLock()
{
    LeaveCriticalSection(&cs);
    return TRUE;
}

SECURITY_ATTRIBUTES sa;
sa = ...

HANDLE mtx;
mtx = CreateMutex(sa, FALSE, NULL);

BOOL AcquireLock()
{
    if(!mtx) { return FALSE; }

    // Pick a timeout. INIFINTE is not timeout.
    DWORD dwWait = WaitForSingleObject(mtx, 5000);
    DWORD dwError = GetLastError();
    assert(WAIT_OBJECT_0 == dwWait || WAIT_ABANDONED_0 == dwWait);

    return  WAIT_OBJECT_0 == dwWait || WAIT_ABANDONED_0 == dwWait;
}

BOOL ReleaseLock()
{
    if(!mtx) { return FALSE; }

    BOOL bResult = ReleaseMutex(mtx);
    DWORD dwError = GetLastError();
    assert(FALSE != bResult);

    return bResult;
}

On Thu, Jun 24, 2010 at 1:25 PM, Massimiliano Pala
<massimiliano.p...@dartmouth.edu> wrote:
> Hi all,
>
> I have a question for Win coders.. I am porting LibPKI, which is based on
> OpenSSL, to Win OSes. On UNiX OSes we used pthread to initialize support
> for threads in OpenSSL.
>
> What is the best practice for Win OS ? Does anybody have some sample code
> around ? In particular, I am referring to the code like:
>
> void OpenSSL_pthread_init(void) {
>
>        int i;
>
>        lock_cs=OPENSSL_malloc((size_t) (((size_t)CRYPTO_num_locks()) *
>                                                sizeof(pthread_mutex_t)));
>        lock_count=OPENSSL_malloc(((size_t) (CRYPTO_num_locks()) *
>                                                sizeof(long)));
>        for (i=0; i<CRYPTO_num_locks(); i++)
>                {
>                lock_count[i]=0;
>                pthread_mutex_init(&(lock_cs[i]),NULL);
>                }
>
>        CRYPTO_set_id_callback((unsigned long (*)())pthreads_thread_id);
>        CRYPTO_set_locking_callback((void (*)())pthreads_locking_callback);
>
>        /* Initializing the OpenSSL dynamic callbacks as well,
>           needed by the nCipher driver */
>        CRYPTO_set_dynlock_create_callback(_dyn_create_callback);
>        CRYPTO_set_dynlock_lock_callback(_dyn_lock_callback);
>        CRYPTO_set_dynlock_destroy_callback(_dyn_destroy_callback);
>
>        return;
> }
>
> One possibility would be to use the port of pthreads for Win.. but I was
> wondering if some of you already went through the process and know the
> best way to provide OpenSSL with thread safety (using native Win calls
> instead of pthread ones?)
>
>
> --
>
> Best Regards,
>
>        Massimiliano Pala
>
> --o------------------------------------------------------------------------
> Massimiliano Pala [OpenCA Project Manager]                   ope...@acm.org
>                                                 project.mana...@openca.org
>
> Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
> PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
> --o------------------------------------------------------------------------
> People who think they know everything are a great annoyance to those of us
> who do.
>                                                           -- Isaac Asimov
>
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to