Clarification on aioble's use of ThreadSafeFlag class. Flags accumulate or is it a bool?

[brianreinhold]

I am not sure how this ThreadSafeFlag class is supposed to work. Is it like a posix semaphore? IN other words, if make a call like this several times:

connection._pair_event = asyncio.ThreadSafeFlag()
connection._pair_event = asyncio.ThreadSafeFlag()
connection._pair_event = asyncio.ThreadSafeFlag()

does it take three connection._pair_event.set() calls to clear it?

I should also ask - if cumulative, is it FIFO or PUSH/POP? If bool and two calls are made, does the last override the first?

Why do I care? Because of bonding and bonded reconnects. It turns out that the btstack (used on the PICO-W port) handles security requests internally. In other words, aioble and the application using aioble have no idea pairing/bonding happened. On the other hand, insufficient authentication/encryption errors have to be handled by the application (calling the aioble pair method). Some devices issue the security request on a first time connect but not a bonded reconnect, and some devices issue a security request instead of an insufficient authentication/encryption error. (Some devices dont pair at all.) Need to handle all cases.

So how to deal with this? First of all, I need to know that pairing/encryption happened under the hood (due to a security request). So I added a method security_request_check to aioble's security module that was identical to its pair method except it did not call the BLE gap_pair() method. All it did was call the connection._pair_event = asyncio.ThreadSafeFlag(). Then I needed to add the RE-ENCRYPTION event in the low level C code to the list of events that triggered the IRQ_ENCRYPTION_UPDATE event in aioble.

Now at the start of every connection, this security_request_check is run as a task and if pairing/encryption is done by a security request, both aioble and the application will know about. The task will terminate should pairing/encryption happen. It works.

But now I have a problem if the device sends an authentication failure error, In this case I have to invoke pairing. So I call the aioble pair method and it also sets the connection._pair_event = asyncio.ThreadSafeFlag(). It works (pairing or encryption ensues at the low levels), but the background security task gets the event when the pairing/encryption is done. For the application, the pairing call remains in the await state until a timeout is reached. Not good. The application is locked until the timeout. So it looks like the events are 'stacked'. I have added another method to aioble's security module

def clear_security_request_check(connection: DeviceConnection) -> None:
    logger.info("LNI: AIOBLE - SEC CHECK: Set event")
    connection._pair_event.set()

which does nothing but set the event again, releasing the pair method. It SEEMS to work but it is a hard thing to test.

In any case, that is why I want to know if repeated calls to asyncio.ThreadSafeFlag() accumulate or is it just a bool?

[glenn20]

asyncio.ThreadSafeFlag() is a constructor, so you are just replacing connection._pair_event with a new instance of a threadsafeflag object each time. If I understand how you a re using it, the effect will not be cumulative, but any tasks waiting on one of the earlier instances may not be released whern you set() the flag later.

See

micropython/extmod/asyncio/event.py

Lines 45 to 64 in 9d27183

	class ThreadSafeFlag(io.IOBase):
	def __init__(self):
	self.state = 0
	def ioctl(self, req, flags):
	if req == 3: # MP_STREAM_POLL
	return self.state * flags
	return -1 # Other requests are unsupported
	def set(self):
	self.state = 1
	def clear(self):
	self.state = 0
	async def wait(self):
	if not self.state:
	yield core._io_queue.queue_read(self)
	self.state = 0

[brianreinhold]

@glenn20 I am hoping you are correct. I have no problem terminating the task that was waiting on the ThreadSafeFlag object. My concern was the newer case NOT getting triggered when the event (pairing/encryption complete) fired. I've written the code that way in any case. To understand what the class is doing I need a better standing of ioctl. I am pretty ignorant in that department.

[glenn20]

On micropython (and python), asyncio is principally designed to detect when "IO devices" have become available for reading or writing - and then making any tasks waiting to read or write to/from those devices available to be scheduled. asyncio waits for IO devices to be ready by polling them using an ioctl() call. This can be implemented in C or python. Any python IO object implementing the ioctl() (MP_STREAM_POLL) call can be used as a "pollable" object by asyncio. This is what Threadsafe flag is used for - it acts as a dummy IO device that lets you decide when it is ready or busy (and so, when a task is schedulable by asyncio). When self.state is 0, asyncio thinks it is "busy". When it is 1, it is ready and an asyncio task waiting on that instance will be available to run.

IF the flag is not already "set",

• await flag.wait() will yield to the asyncio scheduler (yield core._io_queue.queue_read(self))
• this task will be schedulable after the set() method of this instance has been called by another task or ISR
• the first thing the task will do when it resumes is to clear the flag of this instance.

IF the flag is already set, await flag.wait() will return immediately.

I can't tell exactly what behaviour you will see in your code because I don't know how, where and when you are awaiting on the flags and invoking the set() calls. However, you should be able to work it out based on this description.

[glenn20]

eg. in the following code

x = asyncio.ThreadSafeFlag()
x = asyncio.ThreadSafeFlag()
x = asyncio.ThreadSafeFlag()

await x.wait()

the first two lines are completely redundant. Three separate instances are created, but only the third one is being used.