[boost] Lock Classes
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
// File: example.cpp
//
// Copyright (c) 2003
// Kevin Atkinson
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any purpose is hereby granted without
// fee, provided that the above copyright notice appear in all copies
// and that both that copyright notice and this permission notice
// appear in supporting documentation. Kevin Atkinson makes no
// representations about the suitability of this software for any
// purpose. It is provided "as is" without express or implied
// warranty.
//
// Lock Example
#include "lock.hpp"
using namespace distribnet;
class MultithreadedObject
{
public:
void init();
void sync();
private:
void setup(LockState);
void modify1(WillOnlyLock);
void modify2(WillOnlyLock);
void modify3(WillOnlyLock);
void synchronize(WillLock);
void network_function(WillUnlock);
MultithreadedObject()
: counter(0), var1(10), var2(20) {}
int counter;
int var1;
int var2;
Mutex lock;
};
void MultithreadedObject::init()
{
{
Lock l(lock); // will automaticlly unlock at the end of the scope
counter = 0;
var1 = var2 = 99;
setup(l);
}
// now do things that don't need the lock
}
void MultithreadedObject::sync()
{
synchronize(lock); // simply passing in the lock. The lock classes will
// take care of the rest
}
void MultithreadedObject::setup(LockState l)
// will simply pass the lock state around to other functions that may
// lock or unlock
{
modify1(l);
synchronize(l);
}
void MultithreadedObject::modify1(WillOnlyLock)
// If not locked will lock when the function is called and unlock
// when the function returns. Will not unlock otherwise.
{
var1 = 111;
}
void MultithreadedObject::modify2(WillOnlyLock)
{
var2 = 222;
}
void MultithreadedObject::modify3(WillOnlyLock)
{
var2 = 333;
}
void MultithreadedObject::synchronize(WillLock l)
// If not locked will lock when the function is called and unlock
// when the function returns. But is allowed to also Unlock the
// mutex inside the function.
{
modify2(l);
network_function(l); // this is ok becuase I am allowed to unlock
modify3(l);
}
void MultithreadedObject::network_function(WillUnlock)
// If locked will unlock when the function is called and lock when the
// function returns. Also allowed to lock in the middle of the
// function.
{
// use network functions which may block for a long time
}
// File: lock.hpp
//
// Copyright (c) 2002,2003
// Kevin Atkinson
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any purpose is hereby granted without
// fee, provided that the above copyright notice appear in all copies
// and that both that copyright notice and this permission notice
// appear in supporting documentation. Kevin Atkinson makes no
// representations about the suitability of this software for any
// purpose. It is provided "as is" without express or implied
// warranty.
#ifndef DISTRIBNET_LOCK__HPP
#define DISTRIBNET_LOCK__HPP
#include
namespace di
[boost] Lock Classes: FINAL POST
This is my final repost of my Lock Classes. If I do not get any
constructive feedback this time I am going to give up.
These classes have the following features:
1) The ability to acquire a lock and release it when the object
goes out of scope effectively implementing 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
// File: example.cpp
//
// Copyright (c) 2003
// Kevin Atkinson
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any purpose is hereby granted without
// fee, provided that the above copyright notice appear in all copies
// and that both that copyright notice and this permission notice
// appear in supporting documentation. Kevin Atkinson makes no
// representations about the suitability of this software for any
// purpose. It is provided "as is" without express or implied
// warranty.
//
// Lock Example
#include "lock.hpp"
using namespace distribnet;
class MultithreadedObject
{
public:
void init();
void sync();
private:
void setup(LockState);
void modify1(WillOnlyLock);
void modify2(WillOnlyLock);
void modify3(WillOnlyLock);
void synchronize(WillLock);
void network_function(WillUnlock);
MultithreadedObject()
: counter(0), var1(10), var2(20) {}
int counter;
int var1;
int var2;
Mutex lock;
};
void MultithreadedObject::init()
{
{
Lock l(lock); // will automaticlly unlock at the end of the scope
counter = 0;
var1 = var2 = 99;
setup(l);
}
// now do things that don't need the lock
}
void MultithreadedObject::sync()
{
synchronize(lock); // simply passing in the lock. The lock classes will
// take care of the rest
}
void MultithreadedObject::setup(LockState l)
// will simply pass the lock state around to other functions that may
// lock or unlock
{
modify1(l);
synchronize(l);
}
void MultithreadedObject::modify1(WillOnlyLock)
// If not locked will lock when the function is called and unlock
// when the function returns. Will not unlock otherwise.
{
var1 = 111;
}
void MultithreadedObject::modify2(WillOnlyLock)
{
var2 = 222;
}
void MultithreadedObject::modify3(WillOnlyLock)
{
var2 = 333;
}
void MultithreadedObject::synchronize(WillLock l)
// If not locked will lock when the function is called and unlock
// when the function returns. But is allowed to also Unlock the
// mutex inside the function.
{
modify2(l);
network_function(l); // this is ok becuase I am allowed to unlock
modify3(l);
}
void MultithreadedObject::network_function(WillUnlock)
// If locked will unlock when the function is called and lock when the
// function returns. Also allowed to lock in the middle of the
// function.
{
// use network functions which may block for a long time
}
// File: lock.hpp
//
// Copyright (c) 2002,2003
// Kevin Atkinson
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any purpose is hereby granted without
// fee, provided that the above copyright notice appear in all copies
// and that both that copyright notice and this permission notice
// appear in s
[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
[boost] Lock Classes: FINAL POST (fixed attch)
[The attachment got messed up in the last post. Hopefully, it will be OK
this time]
This is my final repost of my Lock Classes. If I do not get any
constructive feedback this time I am going to give up.
These classes have the following features:
1) The ability to acquire a lock and release it when the object
goes out of scope effectively implementing 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
// File: lock.hpp
//
// Copyright (c) 2002,2003
// Kevin Atkinson
//
// Permission to use, copy, modify, distribute and sell this software
// and its documentation for any purpose is hereby granted without
// fee, provided that the above copyright notice appear in all copies
// and that both that copyright notice and this permission notice
// appear in supporting documentation. Kevin Atkinson makes no
// representations about the suitability of this software for any
// purpose. It is provided "as is" without express or implied
// warranty.
#ifndef DISTRIBNET_LOCK__HPP
#define DISTRIBNET_LOCK__HPP
namespace distribnet {
// These lock classes serve three functions:
//
// 1) The ability to aquire a lock and release it when the object
//goes out of scope effectvly 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.
//
// The global lock used to initialize the lock classes.
class Mutex;
// The scoped lock classes:
class LockOnly; // If the lock is not already aquire it will do so
// and then release it at the end of the scope.
// It will not release it under any other
// circumstances.
class Lock; // Will aquire the lock if necessary but may also
// release it at any time. Do not call a function
// with this type of lock while in an inconsistent
// state.
class UnlockOnly; // If the lock is already aquired it will be
// released and then reaquire at the end of the
// scope. If will not aquire a lock under any
// other circumstances.
class Unlock; // If locked is it will be released it, however
// it may reaquire at any time. Do not call a
// function with this type of lock if it is
// unexceptable to wait for the lock to be
// reaquired.
// These locks should never be passed by value to functions.
// Instead use the following typedef to pass by reference:
typedef const LockOnly & WillOnlyLock;
typedef const Lock & WillLock;
typedef const UnlockOnly & WillOnlyUnlock;
typedef const Unlock & WillUnlock;
// The following lock "states" are also provided. When a functions
// takes one of these lock states as a parameter it may change the
// lock state at any time but then again it might not.
class MightLockUnlock; // Might aquire or release the lock or both.
typedef MightLockUnlock LockState; // alternate name
class MightLock; // Might aquire a lock but will not release it
Re: [boost] Lock Classes: FINAL POST (fixed attch)
Kevin Atkinson <[EMAIL PROTECTED]> writes: > 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. >From what I can see here it looks interesting, but what's really needed is a good description of the problem that it's solving with narrated examples that show how you use it to solve those problems. The little example you enclosed isn't very enlightening. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
