[fpc-pascal] USB Human Interface Devices

Jean SUZINEAU Jean.Suzineau at wanadoo.fr
Wed Aug 28 17:00:29 CEST 2019


Le 28/08/2019 à 13:26, James Richters a écrit :
> Thanks for figuring out the critical section needs to be initialized.  Stefan's example did not do this:
> https://github.com/svpantazi/libusbxhid/blob/master/libusbhid_test_with_thread.pp
>
> maybe it's something you can get away with on Linux...
Maybe, it seems EnterCriticalSection is defined by the current thread 
manager. But if your variable is uninitialized, you can have anything in 
it, I think EnterCriticalSection cannot do anything reliable with it.
> I'll put in the init and done.   Should I enter critical section only for writing to shared variables, or also when reading them?

You don't need to enter the Critical section to read the variable.

The critical section is essentially used to prevent the case where your 
main thread and your read  thread write two different values to the same 
variable at the same time. In this case without a critical section, you 
cannot predict the value of the variable. If the variable is always 
written by the same thread, you don't need the critical section.

> I'm also wondering if there is some way to tell if a thread is currently running or not... I don't want to try to start it again if it's already running.  I can make some flag that the threat sets when it starts and clears when it exits, but I am wondering if there already something in place to check to see if a thread exists.

You can find whether your thread is running or not with the 
readThread.Suspended property,

but in your program, your thread is always running, it's nether 
suspended. It's just blocked in a call (to libusbhid_interrupt_read I guess)




More information about the fpc-pascal mailing list