I posted this a couple days ago and have yet to seen any sort of reply or
any sign that anyone is interested. If people are having trouble
understanding the concept please let me know and I will try harder to
explain it. If you meant to reply but haven't yet, sorry for being
impatient.
If no one responds to this email I will assume no one cares and will give
up. Even though I think it is useful I don't have the time to push it.
Original Message:
Attached is a series of lock I created for one of my projects. These
classes have the following features.
1) The ability to acquire a lock and release it when the object
goes out of scope effectively implemented the "Monitor" concept.
2) Avoid the need for recursive locks by careful and efficient
book keeping with the out the use of global thread specific
data.
3) Document and enforce guaranteed lock behavior for functions
which take a lock class as a parameter.
Recursive locks may avoid the need for the bookkeeping. However recursive
looks are more expensive. Also, with recursive locks, as far as I know,
it is imposable to temporally release the lock. For example when calling
a network function I don't want to keep the lock as the object is in a
consistent state and holding the lock while waiting for a reply will
greatly reduce concurrency. My lock classes makes this possible to do
efficiently and safely as it is not possible to accentually call a
function that will release a lock without giving it permission to do so.
The only downside is that you have to explicit pass the lock around to
each function as a parameter. My recommendation is to use the lock
classes as parameters to private methods or functions which may call each
other and thus need to avoid acquiring a non recursive lock more than
once. Public members can than call the private members by simply
providing the function with the appropriate lock.
I have not seen anything quite like it so I thought I would share it here
and see what other people think.
Feedback on the idea or implementation welcome. This code, at the moment,
does not follow boost standards. If people think it is a worthy addition
to boost I will be willing to being it up to boost standards. But for
right now please refrain from making comments on coding style or the
like.
--
http://kevin.atkinson.dhs.org
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
