[boost] Lock Classes: Does anyone care.
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
Re: [boost] Lock Classes: Does anyone care.
Kevin, we're currently in the middle of a release and a formal review... If you wait a week or so.. and recall our attention, you're likely to get a response. Just hold on. Thanks, Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Lock Classes: Does anyone care.
On Tue, 18 Feb 2003, Fernando Cacciola (Home) wrote: > Kevin, we're currently in the middle of a release and a formal review... > If you wait a week or so.. and recall our attention, you're likely to get a > response. > Just hold on. No problem. I'm in no rush. If I don't get any response expressing serious interest I will repost in two weeks. -- http://kevin.atkinson.dhs.org ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Lock Classes: Does anyone care.
On Wed, 19 Feb 2003, William E. Kempf wrote: First off, just in case you didn't realize it, this message was directed at one person not the group in general. I cced it to the list. I *hate* forced reply-to. > > Are you, or are you not interested in my Lock Classes. The messages I > > got from you is that you are only interested in my lock classes if > > I haven't had a chance to really evaluate anything here. You'll have to > give me some more time. No problem. > > 1) It is reproposed as an extension to the locking mechanism in Boost > >thread. > > and/or > > I'd say it would at least have to play nice with Boost.Threads. If *I* > find the idea interesting, I'd personally lean towards making it part of > Boost.Threads. But technically that wouldn't be an absolute requirement > for it being considered by Boost at large (even if I'd suspect you'd find > many people interested only if it were part of Boost.Threads). Well as I said in a previous email my Lock Classes can be used on top of any locking mechanism. I used POSIX locks since that I what I used in my project. But by Mutex class can be substituted by any class that offers a lock() and unlock() methods or the equivalent of them. > > 2) It is reworked to somehow be an extension of the smart pointer > >concept, even though it has very little relation to smart pointers. > > I haven't looked at this at all, so I can't comment too much. But there's > a lot to be said for having a "locking_ptr" concept, which may be why > people are advocating it here. Well as I said before, as far as I know, the only type of pointer like management that will make sense for a Mutex is a scoped_ptr. This concept is already implemented in Boost.Thread and not very interesting. > and since we're in a crunch time, like Beman and others have pointed > out, you'll not get that kind of feedback, pro or con, at this point in > time. No problem. I will repost latter if I don't get any serious interest now. -- http://kevin.atkinson.dhs.org ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
