On Sat, May 3, 2014 at 1:34 AM, Danesh Daroui <danesh.daroui@gmail.com> wrote:
> Thanks for your answer. I guess threads is something that I was looking for.
> By concurrency I meant being able
> to spawn multiple threads which will logically run in parallel. Moreover
> having the possibility to define mutex
> and semaphores which are apparently done in Pike (mutex is at least done)
> and also barrier and join threads, etc.

Yep! You should be able to do all that.

Pike's own internals are guaranteed to be thread-safe, so you can
happily work with all the refcounted objects from multiple threads.
(This will damage "true concurrency", though, as accessing the same
object from two threads means they'll lock against each other. In
practice, this happens a lot, so you'll probably not be able to use
multiple cores to maximum efficiency without some alternative ways of
fiddling with things.) I run a MUD by the name of Minstrel Hall
(minstrelhall.com) where every connected client has a separate thread;
they all run very happily together. One can interact with another and
they don't have to worry about treading on each other's toes.

For actual explicit locking between threads, the Thread module
provides mutexes. They're a little odd to use at first, if you're used
to a more classic mutex system; but it's very handy because you can't
accidentally forget to unlock the semaphore (once the MutexKey goes
out of scope, the Mutex is automatically unlocked). I've used it
occasionally, but it's almost never necessary.

Operations like joining threads are provided as methods on the
Thread.Thread object (eg wait()). I'm not sure where barriers would be
needed, as I've never actually used them in any language, but I'm sure
there'll be a way to implement it.

ChrisA