Re: Free lightweight C++ signals and slots library
On 27/08/2012 15:00, Chris Vine wrote:
On Mon, 27 Aug 2012 14:16:16 +0100
Leigh Johnston <leigh@i42.co.uk> wrote:
On 27/08/2012 13:46, Chris Vine wrote:
On Thu, 16 Aug 2012 00:09:22 +0100
Leigh Johnston <leigh@i42.co.uk> wrote:
On 15/08/2012 21:20, Marcel M?ller wrote:
On 13.08.2012 16:26, Leigh Johnston wrote:
An event handler can fire other events no problem if the
programmer knows that it is the same thread (which is almost
certainly the case if the programmer is in control of the
software design).
If an event handler can safely fire other events (with the
restriction), it must always be called from the same thread. And
furthermore the event that it fires must also always be called by
the same thread only. In fact that means that your application
must be single threaded with respect to event processing.
But if there is a strict ordering of all events, i.e. event A can
call ebent B but never the other way around, then none of the
restrictions apply.
I have changed the default locking policy to "shared mutex" which
should prevent deadlocks; I have also added asynchronous signalling
allowing an event to be posted from one thread to another.
A signal/emitter/dispatcher object (whatever you choose to call it)
shouldn't execute connected slots/delegates while holding any of its
private mutexes. The connected slots/delegates could do anything:
the abstraction of this programming pattern is wasted if the user
has to worry about recursive or out of order locking on the signal
object's own mutexes when emitting.
Even if you use recursive mutexes to permit recursive locking, you
would still leave yourself open to the problem of out of order
locking with other signal objects' mutexes if you expose them in
this way.
The library works fine with shared recursive mutex; no deadlocking;
but you can also choose individual mutex or no mutex; it is quite
flexible.
It can't work fine, because the signal::trigger() method executes
delegates holding whatever locking policy type is chosen. A shared
mutex (read-write lock) policy type will not solve the problem of out
of order or recursive locking where one of the locking operations is
for a write. Whenever you have to resort to recursive locking warning
lights should start flashing, and in this particular case it is a
deadlock waiting to happen.
With a shared mutex there are no deadlocks; with different mutexes you
can avoid deadlocks by not using signals and slots across threads; the
library is flexible enough to achieve its aims.
The following code does not deadlock (but the first thread will block
the second thread for ten seconds):
#include <neolib/neolib.hpp>
#include <iostream>
#include <string>
#include <neolib/io_thread.hpp>
#include <neolib/signal.hpp>
#include <neolib/slot.hpp>
neolib::signal<void(const std::string&)> on_event_1;
neolib::signal<void(const std::string&)> on_event_2;
class thread_one : public neolib::io_thread, public neolib::has_slots<>
{
public:
thread_one() : iCount(0)
{
on_event_1(*this, &thread_one::handler);
}
private:
virtual void task()
{
on_event_1.trigger("from task()");
while(iCount != 2)
do_io();
}
void handler(const std::string& aFrom)
{
++iCount;
std::cout << "thread_one::handler(\"" << aFrom << "\")" << std::endl;
if (iCount == 1)
{
sleep(10000);
on_event_2.trigger("from handler()");
}
}
private:
std::size_t iCount;
};
class thread_two : public neolib::io_thread, public neolib::has_slots<>
{
public:
thread_two() : iCount(0)
{
on_event_2(*this, &thread_two::handler);
}
private:
virtual void task()
{
on_event_2.trigger("from task()");
while(iCount != 2)
do_io();
}
void handler(const std::string& aFrom)
{
++iCount;
std::cout << "thread_two::handler(\"" << aFrom << "\")" << std::endl;
if (iCount == 1)
{
sleep(5000);
on_event_1.trigger("from handler()");
}
}
private:
std::size_t iCount;
};
void deadlock()
{
thread_one t1;
thread_two t2;
t1.start();
t2.start();
t1.wait();
t2.wait();
}
The above code will deadlock if you move from shared_mutex locking
policy to individual mutex locking policy.
If you don't want the features that neosigslot provides then you can use
boost.signal2. I prefer my library as I like its features (auto
disconnect, re-entrancy, handling slot destruction during notification
and signal keys; features which require locking).
/Leigh