[interfacekit] Re: BHandler::fToken

This whole topic has reached the state of being completely theoretical ( 
as illustrated below).  Nevertheless, I trudge onward ... ;)

Marcus Overhagen wrote:
>>The issue isn't how hard it is to find a known token value; the issue is 
>>the speed with which we can find the first available *unused* token 
> 
> That's easy. Just atomic=5Fadd() some 32 bit counter, and each time you do it.

Yes; that's already happening.

> you get a fresh token. If you think it will overflow, use a 64 bit counter and
> 64 bit tokens.

That would work nicely, wouldn't it?  Duh. =P

>>value.  As BHandler-derived instances are destroyed, they return their 
>>token to BTokenSpace; that token can now be reused.  BTokenSpace keeps 
> 
> Please don't reuse tokens. It's not funny if an invalid BMessenger (for 
> example)
> get's valid again and targets another target.

The point was to deal with the outside case of maxing out the token counter.

>>In the *extremely* unlikely event that an application actually manages 
>>to request 32 bits worth of tokens in a given execution, the counter 
>>will max out and BTokenSpace will have to start using returned tokens. 
> 
> Did you calculate how likely that is=3F 
> Let's assume the computer needs to run for 10 Years continuously.
> You have 4.294.967.295 unique tockens in a uint32.
> That will allow to create 817 new tockens every minute, or 13 tokens
> every second running ten years!

Actually no, but now that you have, I feel pretty comfortable entirely 
ditching the idea of a cache. =)

> That won't work. Assume you limit the queue to 10.000 tokens.
> When these are exhausted, you need to refresh it somehow (walking the map=3F)
> If you don't limit the queue size, you will need about 16 GB to store them.

The idea is that as BHandlers are destroyed, they return their tokens to 
BTokenSpace and some number of these returned tokens would be stored in 
the queue.

> Using a 64 bit token space would be better (less memory, faster) solution, 
> if you really need more than 32 bit.

Yes, and I feel a bit silly not having thought of it myself. =P

>>Hope that clears the air a bit. ;)
> 
> Well, I hope you are not serious about storing all unised tokens in a queue.

As I said earlier, there would be a cap on the size of the queue.  A 
couple hundred, maybe a thousand.  I was planning on storing some number 
of *returned* tokens -- i.e., a subset of the unused tokens; one that 
*doesn't* have to be searched to find an available token in the event 
that the counter overflows.

Anyway, this is all moot.  Given your figures above, I'm getting rid of 
the cache.  If an app manages to chew up the entire 32 bit token space 
in the span of a single execution, it'll just end up in the debugger or 
something. =)

e

Other related posts: