Hi Chris,
Thank you for your comprehensive answer. Its good to know that Pike supports such important features and I am actually very keen to discover how mutex works in Pike. However, I guess concurrency was not in the main focus when Pike was designed but it is still very good that it supports something like POSIX threads. Maybe it would be handy to add some new features, so loop parallelization or race condition detecting (like cilk add-on for C) would be possible in Pike too but it really depends on the class of applications that Pike is mostly used for.
Thanks,
D.
On Fri, May 2, 2014 at 5:52 PM, Chris Angelico rosuav@gmail.com wrote:
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