Question for software engineering pros

[Karlos]

@bloodline

When implementing the threadable class in my layer I opted for wrapping the semaphore into a Lockable service class. I also made a Lock class that simply takes any Lockable class and exclusively locks it on construction and then unlocks it on destrution.

With this, making java like "synchronized" methods was easy. Simply do

void MyClass::someSynchronizedMethod() // MyClass inherits Lockable
{
   Lock lock(this); // will lock the MyClass instance
   // blah
}

Voila. Any return from the method, be it normally or by exception causes the Lock object to be destroyed, which in turn calls the unlock method of the object in question.

[Karlos]

@Speel

I guess this is a little off topic... but I'm good at that :-)

Lock as in mutex? I guess -  one thread can use the object at a time, forcing others to wait their turn. First come, first serve.

The Lock class is just an auxilliary that calls the locking (semaphore based on the AmigaOS version) methods for the Lockable derived class. But to answer your question, in the example I posted it ensures that the thread calling that particular method has a totally exclusive lock on the resource (in this case, the specific instance of the MyClass object, whatever that may be).

There are other Lock auxiliaries, such as LockReadOnly, which gets a shared lock. They use the specific "wait for a lock" methods of the Lockable class, so if the object is in use by another thread, the calling thread waits.

Lockable also supports "attempted" locks, where if the object is busy you don't get it and you dont wait either. To implement auxiliaries for these I saw no real way but to use an exception, thrown on construction of the auxiliary. The problem there is that I am trying like hell to avoid using exceptions in my layer due to quality of implementation / thread-safetu problems regarding exceptions in general.

Of course, you can manually call the Lockable inherited methods yourself. These Lock / LockReadOnly are merely convenience tools ;-) They have next to no overhead since each one simply encapsulates a Lockable* pointer that is passed on construction.

I basically wanted to give something a bit like the synchronized qualification in Java, but of course you can't exactly do that in C++. So these little "declare and forget" auxilliary classes work well for making these method calls behave that way.

The whole mechanism on AmigaOS simply wraps the SignalSemaphore. And it works a charm.

[Karlos]

@Bloodline

Lets assume I have a C++ class "MySock" I'm making using my C++ layer. I want to make it threadsafe such that an instance of the object can be locked (ie in the sempahore sense).

First of all, I make my class inherit Lockable. This is a service class that effectively wraps the semaphore. Amongst its methods are tryLock(), waitLock(), tryReadOnlyLock(), waitReadOnlyLock(), freeLock() etc.

class MySock : public Lockable {
// blah....
};

Suppose I have some critical resource in MySock that must not be accessed concurrently. I can manually call the waitLock() method for the MySock instance and then  call freeLock() when I'm done. This all works pretty simply.

So, you might write a function which does this (assumes no errors in locking, for simplicity's sake)..

void blah(MySock* sock)
{
sock->waitLock();
//.. do stuff to sock, no other thread can intervene
sock->freeLock();
}

Pretty simple so far.

The next thing I did was to make an Auxilliary class called Lock. It looks like this (again error handling is ommitted for clarity):

class Lock {
private:
Lockable* lock;
public:
Lock(Lockable* l) : lock(l) { lock->waitLock(); }
~Lock() { lock->freeLock(); }
}

All this does is to lock the Lockable object passed to it on construction and release the lock on destruction. This is a handy way of automating the above manual locking. We'd simply reimplement the blah function as follows:

void blah(MySock* sock)
{
Lock myLock(sock); // this automatic instance of Lock will lock the sock for the current thread.

//.. do stuff to sock, no other thread can intervene

// on return, the 'myLock' object is destroyed, thus releasing the current thread's exclusive lock on the sock.
}

Does this make more sense now?

-edit-

Ah, I see you got it :-) This is what happens when you write a long post and get interrupted by the boss :lol:

Basically what Speel said :-)

-edit2-

I should further point out that all the queueing and what not is handled automatically by the SignalSemaphore wrapped by the Lockable class. Othe OS's implement lockable in whatever way makes most sense for them, provided the behaviour of Lockable remains the same.

[Karlos]

bloodline wrote:
Cheers karlos... anyway, back on topic, I'd still like to see better support for multithreading built into C/C++ :-D

But the point of C++ is that you build into it what you need by creating classes that encapsulate the functionality you desire ;-)

But having a threadsafe exception model built in would be ideal. You have no idea how deadly StormC 3 (and 4 unless you use threadsafe.lib) is when you throw an exception from one thread and it gets caught in another :lol:

In fact, I think my first serious developer post was about this :-)

@Cymric

I'm just a boring geek that likes to reinvent stuff via class APIs. Don't mind me ;-)

[Karlos]

Cymric wrote:
@Karlos:

You seem to like your Locks, Semaphores, Threads and what-not pretty much.

You forgot Socks and ASCII :lol:

Have you ever looked at this link? It's the most comprehensive tutorial on those techniques I know and contains tons of do's and dont's.

Interesting :-)

[Karlos]

:lol:

I wondered how long it would take :-D

I can see bloodline taking on the sock tester with an almost luddite like zeal!

X-D : "It's ma job! Ma job! Ye' listenin' pal, eh? Ma job! Ah did'ne  work ma bone to the bone fer five feckin years so as ah could be replaced by this so called technological innovation! Ye' can shove your sock tester up yer arse!! Ah got all the sock testin' hardware ah need, thak ye very much pal. Ahh AROS, who's yer feckin' daddy..."

[Karlos]

Not pleasant is it?

So anyway, this thread has derailed totally now :-)

Although I think the threads and stuff was sort of off topic. Or was it? I can't remember :lol:

[Karlos]

bloodline blurted:

"...Everyone else has had more sex than me..."

Is there a computer enthusiast living or dead who has never thought this at least once? :lol: