LUMIERA.clone/src/lib/sync-classlock.hpp
Ichthyostega d6167c1845 DependencyFactory: reorder destructor to allow for re-entrance
This is borderline yet acceptable;
A service might indeed depend on itself circularly
The concrete example is the Advice-System, which needs to push
the clean-up of AdviceProvicions into a static context. From there
the deleters need to call back into the AdviceSystem, since they have
no wey to find out, if this is an individual Advice being retracted,
or a mass-cleanup due to system shutdown.

Thus the DependencyFactory now invokes the actual deleter
prior to setting the instance-Ptr to NULL.
This sidesteps the whole issue with the ClassLock, which actually
must be already destroyed at that point, according to the C++ standard.
(since it was created on-demand, on first actual usage, *after* the
DependencyFactory was statically initialised). A workaround would be
to have the ctor of DependencyFactory actively pull and allocate the
Monitor for the ClassLock; however this seems a bit overingeneered
to deal with such a borderline issue
2018-04-01 07:06:58 +02:00

87 lines
3.1 KiB
C++

/*
SYNC-CLASSLOCK.hpp - special case of object based locking tied directly to a type
Copyright (C) Lumiera.org
2008, Christian Thaeter <ct@pipapo.org>
Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
/** @file sync-classlock.hpp
** A special implementation of lib::Sync, where the storage of the object monitor
** is associated directly to a type rather then to a single object instance. While
** being problematic in conjunction with static startup/shutdown, doing so is sometimes
** necessary to setup type based dispatcher tables, managing singleton creation etc.
**
** @note simply using the ClassLock may cause a Monitor object (with a mutex) to be
** created at static initialisation and destroyed on application shutdown.
** @see depend.hpp usage example
** @see SyncClasslock_test
*/
#ifndef LIB_SYNC_CLASSLOCK_H
#define LIB_SYNC_CLASSLOCK_H
#include "lib/nobug-init.hpp"
#include "lib/zombie-check.hpp"
#include "lib/sync.hpp"
namespace lib {
/**
* A synchronisation protection guard employing a lock scoped
* to the parameter type as a whole, not an individual instance.
* After creating an instance, every other access specifying the same
* type is blocked.
* @note the Lock is recursive, because several instances within the same
* thread may want to acquire it at the same time without deadlock.
* @note there is a design sloppiness, as two instantiations of the
* ClassLock template with differing CONF count as different type.
* Actually using two different configurations within for a single
* class X should be detected and flagged as error, but actually
* just two non-shared lock instances get created silently. Beware!
* @see Sync::Lock the usual simple instance-bound variant
*/
template<class X, class CONF = RecursiveLock_NoWait>
class ClassLock
: public Sync<CONF>::Lock
{
typedef typename Sync<CONF>::Lock Lock;
typedef typename sync::Monitor<CONF> Monitor;
struct PerClassMonitor : Monitor {};
Monitor&
getPerClassMonitor()
{
static PerClassMonitor classMonitor;
static ZombieCheck zombieCheck;
zombieCheck();
return classMonitor;
}
public:
ClassLock() : Lock (getPerClassMonitor()) { }
};
} // namespace lib
#endif /*LIB_SYNC_CLASSLOCK_H*/