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 <[email protected]> wrote: > On Sat, May 3, 2014 at 1:34 AM, Danesh Daroui <[email protected]> > 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 >
