Scott Gilbert: > What happens when you've locked the buffer and passed a pointer to the I/O > system for an asynchronous operation, but before that operation has > completed, your main program wants to resize the buffer due to a user > generated event? That is up to the application or class designer. There are three reasonable responses I see: throw an exception, buffer the user event, or ignore the user event. The only thing guaranteed by providing the safe buffer interface is that the pointer will remain valid. > > I don't want counting mutexes. I'm not defining behavior that needs > > them. > > > > You said you wanted the locks to keep a count. So that you could call > acquire() multiple times and have the buffer not truly become unlocked > until release() was called the same amount of times. I'm willing to adopt > any terminology you want for the purpose of this discussion. I think I > understand the semantics or the counting operation, but I want to > understand more what actually happens when the buffer is locked. When the buffer is locked, it returns a pointer and promises that the pointer will remain valid until the buffer is unlocked. The buffer interface could be defined either to allow multiple (counted) locks or to fail further lock attempts. Counted locks would be applicable in more circumstances but require more implementation. I would prefer counted but it is not that important as a counting layer can be implemented over a single lock interface if needed. Neil
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4