typedef void *TOpaque;
typedef struct
{
int spin;
void *mem;
int size;
} TMutex;
typepdef struct /* Use this as the header for all lockable classes */
{
TMutex *ObjectLock;
TMutex *ClassLock;
/* ... */
} TObjTemplate;
TMutex MutexPool[MAXMUTEXES];
int TestSetObject(TOpaque *obj)
{
/*** begin critical section ***/
/* test and set Class's spin lock */
/* test and set Object's spin lock */
/* unset Class's spin lock */
/*** end critical section ***/
}
int TestSetClass(TOpaque *cls)
{
/*** begin critical section ***/
/* test and set Class's spin lock */
/*** end critical section ***/
}
The program can allocate the mutexes from the MutexPool, locking the section like a regular protected memory section.
*NOTE*: Someone had mentioned not wanting to lock the individual instances (objects), instead we should continue to lock at the class level. Maybe I misread, but that seems rather inefficient. Without completely knowing the entire SSL subsection, I think that organizing the usage based on threaded sections and instances will maximize multitasking/multiprocessing better.
-Sean Walton
Rich Salz wrote:
[EMAIL PROTECTED]">structure itself. I'd do a malloc(size_of_mutex() + sizeof(RSA)) and
return a pointer to the RSA part of that blob. I haven't thought
through everything yet.
You can't do that; pthreads, for example, often implement the mutex as an
opaque pointers.
/r$
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
