Question for software engineering pros

[Cymric]

Quite recently (I forget where and when, might have been on this forum) I began to wonder what the Next Big Thing in software engineering is going to be. We've had quite a lot of experience with OOP now, to the point where there are already plenty of books which can comfortably write about the good and the bad of it---and not just spew marketing hype.

I can guess that threading and parallelisation are going to be quite important topics, now that the big CPU vendors are slowly inching towards multiple (quite possibly vectorised) cores on a single chip. Quite a number of people have pointed out that sticking a second core on a die is not a recipe for double performance, you need to be intelligent about it. (I recall Hammer pointing out, in his own informative if a little terse way, that vectorised GFX-chips are very sensitive to their drivers; so sensitive that nVidia abandoned their attempts at selling them.)

But are there other things which are currently just below the horizon?

[Speelgoedmannetje]

In the spirit of Amiga, I like the idea of OOP applied in hardware. But certainly not the CISC way.
But I know someone who already thought this way at least 20 years ago.

[bloodline]

Cymric wrote:
Quite recently (I forget where and when, might have been on this forum) I began to wonder what the Next Big Thing in software engineering is going to be. We've had quite a lot of experience with OOP now, to the point where there are already plenty of books which can comfortably write about the good and the bad of it---and not just spew marketing hype.

I can guess that threading and parallelisation are going to be quite important topics, now that the big CPU vendors are slowly inching towards multiple (quite possibly vectorised) cores on a single chip. Quite a number of people have pointed out that sticking a second core on a die is not a recipe for double performance, you need to be intelligent about it. (I recall Hammer pointing out, in his own informative if a little terse way, that vectorised GFX-chips are very sensitive to their drivers; so sensitive that nVidia abandoned their attempts at selling them.)

But are there other things which are currently just below the horizon?

Good question, I would put money on the next big thing being better support for Multithreading.

Languages like Occam had extensive support for asynchronous objects and paralisation... I want to see stuff like that incorporated into C/C++ compilers, dealing with Mutexes and semaphores is a bit of a pain :-)

[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.

[T_Bone]

http://www.threeseas.net/

[Speelgoedmannetje]

@Karlos,
with locks, you mean MUTEXes, I guess?

[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.

[bloodline]

Karlos wrote:

What? :-?

[Speelgoedmannetje]

@bloodline
Karlos was talking about an algorithm to deal with data, so two or more seperately running programs within a program (called threads) cannot acces the same data at the same time. If I know it correctly, if a thread wants to acces the data at the same time as another thread, it is placed in a queue. (plus some more features like that)
very nice indeed to prevent lockups :-)

[bloodline]

Speelgoedmannetje wrote:
@bloodline
Karlos was talking about an algorithm to deal with data, so two or more seperately running programs within a program (called threads) cannot acces the same data at the same time. If I know it correctly, if a thread wants to acces the data at the same time as another thread, it is placed in a queue.
very nice indeed to prevent lockups :-)

Ahhh, a queue for the mutex, got it :-)

[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.

[bloodline]

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

[Cymric]

@Karlos:

You seem to like your Locks, Semaphores, Threads and what-not pretty much. 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.

[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 ;-)

[Cymric]

@bloodline:

That's an interesting suggestion. However, for C those extensions already exist: do a Google search for 'Earth' and 'threaded C'.

However, I don't think it is wise to include multithreading support in the core language just like that. Threading is extremely dependent on the OS itself, and while most systems nowadays support POSIX-type threads, there are tons of little changes and additions in each OS. Plus you must be wary of the difference between kernel space threads and user space specimens. Some systems have just one type, the others mix them at will. Various system resources may be shared differently and thus have different visibility depending on what system you run the code. There are so many tiny quirks that I doubt adding threading support to a low-level language like C or C++ will result in something useful since most functionality will be moved to the runtime system anyway.

It's akin to neither C nor C++ offering a good, standard memory management package. I know some people prefer to clean up after themselves, but for rapid prototyping, such details are really not something you want to be bothered with. (It is also the reason why we have so many insecure systems, details and deadlines usually don't mix ;-).)