Michael Plante wrote:
>> Yes, it presently uses a mutex. Like I said, that is not a difficult
problem. The only
>> issue with the default context is making sure that mutex only gets
overwritten once, and
>> this can be done with an InterlockedCompareExchange() (are HANDLE's 32
or 64-bits in
>> 64-bit Windows? If 64, it might need to be
InterlockedCompareExchangePointer().). Or,
>> if it's done via static initialization, that it get torn down, and that
we check for
>> errors during init.
>>
>> The condition variable is difficult. I was merely trying to be complete
by listing the others.
Since none of the synchronization objects are exposed in libusb.h, would it
make sense to define some inline functions in libusbi.h that call out to
either Win32 or pthreads, and then create two typedefs: 1 for standalone
mutexes, and 1 for a struct containing a mutex and a condition variable?
(The reason for the struct would be because it may be something completely
different inside the struct in Win32.) For the mutexes (even the static
one), the preprocessor output should be identical to the old code, and for
the condition variable, it'll only be slightly different.
The primitives needing to be replaced are (assuming we ignore
dpfp_threaded.c) :
pthread_mutex_init/pthread_mutex_destroy
pthread_mutex_lock/pthread_mutex_unlock
pthread_mutex_trylock
pthread_cond_init /pthread_cond_destroy
pthread_cond_broadcast
pthread_cond_wait
pthread_cond_timedwait
PTHREAD_MUTEX_INITIALIZER (used only for the default context lock)
pthread_mutex_t
pthread_cond_t
What I would suggest for standalone mutexes is along the lines of:
#ifdef OS_WINDOWS
#define libusb_mutex HANDLE
#else
#define libusb_mutex pthread_mutex_t
#endif
#ifdef OS_WINDOWS
static int _inline libusb_mutex_init(libusb_mutex *mutex, void const *attr)
{
if(! mutex) return ((errno=EINVAL));
*mutex = CreateMutex(NULL, FALSE, NULL);
if(!*mutex) return ((errno=ENOMEM));
return 0;
}
#else
static int inline libusb_mutex_init(libusb_mutex_t *restrict mutex,
const pthread_mutexattr_t *restrict attr) {
return pthread_mutex_init(mutex, attr);
}
#endif
#ifdef OS_WINDOWS
#define PTHREAD_MUTEX_INITIALIZER NULL
static int _inline libusb_mutex_static(libusb_mutex *mutex) {
libusb_mutex temp_mutex; // N.B.: (opaque) pointer; stack is ok
if (libusb_mutex_init(&temp_mutex, NULL))
return 0; // fail
if (InterlockedCompareExchangePointer(
mutex, temp_mutex, NULL)) {
libusb_mutex_destroy(&temp_mutex);
}
return 1; // succeed
}
#else
static int inline libusb_mutex_static(libusb_mutex *mutex) {
return 1; // don't have to fake it.
}
#endif
#ifdef OS_WINDOWS
static int _inline libusb_mutex_lock(libusb_mutex_t *mutex) {
DWORD result;
if(!mutex) return ((errno=EINVAL));
result = WaitForSingleObject(*mutex, INFINITE);
if(result == WAIT_OBJECT_0 || result == WAIT_ABANDONED)
return 0; // acquired (abandoned is bad, but I don't know mapping)
return ((errno=EINVAL)); // don't know how this would happen, so don't know
proper errno
}
#else
static int inline libusb_mutex_lock(libusb_mutex_t *mutex) {
return pthread_mutex_lock(mutex);
}
#endif
In libusb_init():
+ if(!libusb_mutex_static(&default_context_lock))
+ goto err;
pthread_mutex_lock(&default_context_lock);
...and so on. No change is needed to the static definition. Again, this
leaks one mutex per process execution, but for many programs, that's a
difference of milliseconds between when it's freed by the OS and when it
could be freed by libusb_exit(), and a small known-constant # is acceptable,
IMHO. I didn't try compiling these, so there may be problems, but I think
it gets the idea across.
I want to be careful about pthread_* name collisions, since when I use
libusb on Win32, I already have a pthread dependency for unrelated reasons.
Maybe it's not an issue...
Thoughts?
Thanks,
Michael
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com_______________________________________________
Libusb-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusb-devel
Locked
