I was wondering how Binders work internally when it comes to serve multiple processes at the same time.
I tried to walk over the driver's code but it was a little bit complicated. However, if I'm not mistaken, I've seen the code includes some locks when performing transactions, but not exactly sure the scope of those locks.
As you know, Binder service includes a thread pool (of 16 threads) which is to increase concurrency to serve multiple processes at the same time. My confusion comes here. If the binder driver itself uses some kind of a global lock to serialise the access, how the entire binder framework take advantage of this thread pool?
The only valid answer comes up to me is the binder might be using some "granular" locks then release it to keep things (threads) going up to the service-side thread pool.
I might be completely or partially wrong on this. Any help would be very much appreciated.
PS: If locking is like "granular" then how the global read/write buffer (if any) is protected against potential multiple read/writes coming from multiple processes. Or, are those buffers in the thread stack (so protected by nature)?
