Re: [fpc-pascal] getting started with threads
Helmut Hartl pisze: -Original message- From: Dariusz Mazur dar...@emadar.com Sent: Fri 18-09-2009 16:24 To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org; Subject: Re: [fpc-pascal] getting started with threads David Emerson pisze: I am getting started with threads (linux/cthreads) and I'm very happy so far, but unsure of the best way to tackle my situation. I have a program that needs to perform about 10,000 independent tasks, which usually involve waiting for I/O; thus it makes sense to use several threads so that some waiting can be done in parallel. I thought I'd try it with 10 threads. You need FIFO queue for multiple consumer. Each task can be assigned to them. You can use ordinal tThreadList but it rather slow. I use own lockfree FIFO http://www.emadar.com/fpc/lockfree.htm to distribute task between threads its much faster and well scaling on multicore. I had (only) a quick look at your implementation but i have the bad feeling that it suffers from the ABA problem. Normally it has a low probability to occur but nevertheless extremely hard to find errors occur occasionally. Its save about ABA problem, only it atomic operation are true atomic. I try to test both: theoretical and in real. But if You know sequence, that things may go wrong, pleas tell it. The problem is avoided by using a 64 Bit CAS with a tagged pointer. I have such a implementation under BSD Licence which i can donate for review and public use. But it only works for 32 Bit x86 archs by now, as i am not sure if there is a consistent support of a 128 Bit CAS on all x86 chips. (my last knowledge was that not all xeon/pentium steppings support it) 64bit CAS is absent on many platforms, and is slower but I'd like too see Your implementation Have a look at (as example): http://www.cs.rochester.edu/~scott/papers/1996_PODC_queues.pdf Lot's of interesting publications in the field can be found at the ACM (http://www.acm.org/), but you need to be member to have access to the digital library. thx for links -- Darek ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: getting started with threads
Graeme Geldenhuys wrote: So far I have single interface for create/destroy/lock/unlock of semaphores for Windows, Linux, *BSD. The latter two is actually for all A semaphore is not locked and unlocked, it is posted and waited for. Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] getting started with threads
Jonas Maebe wrote: on x86 too). Atomic operations are not memory barriers by themselves, and the fact that you perform an atomic operation does not mean that afterwards all cpu's will immediately see this new value. Explain? Isn't the point of an atomic update that it doesn't matter whether the other CPU has seen the value yet? Or are we talking about different values? Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] getting started with threads
On 19 Sep 2009, at 10:36, Micha Nelissen wrote: Jonas Maebe wrote: on x86 too). Atomic operations are not memory barriers by themselves, and the fact that you perform an atomic operation does not mean that afterwards all cpu's will immediately see this new value. Explain? Isn't the point of an atomic update that it doesn't matter whether the other CPU has seen the value yet? Or are we talking about different values? Yes, sorry for being unclear. One problem is that unless all of the data to which the queue elements point is also only loaded/stored using atomic operations, it is possible that the popping cpu will see different values than those intended the pushing cpu (because their caches may not yet have been syncronised). So at least for the pop you need a full memory barrier. There are probably more issues. Here's a page with several different atomic queue implementations for ppc, and all of them contain some form of barrier: http://www.cocoadev.com/index.pl?AtomicSQ Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: getting started with threads
2009/9/19 Micha Nelissen mi...@neli.hopto.org: A semaphore is not locked and unlocked, it is posted and waited for. True, and to let it make even more sense (technically correct) one might have to use method names like deccount() / inccount() or grabitem() / releaseitem() etc etc... Either way, internal implementation calls the correct post- and wait- API's of each platform. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: getting started with threads
On Sat, 19 Sep 2009 10:25:20 +0200, Micha Nelissen wrote about Re: [fpc-pascal] Re: getting started with threads: Graeme Geldenhuys wrote: So far I have single interface for create/destroy/lock/unlock of semaphores for Windows, Linux, *BSD. The latter two is actually for all A semaphore is not locked and unlocked, it is posted and waited for. An event semaphore (or condition in POSIX-speak) is waited for and posted. A simple mutex semaphore is locked and unlocked -- or, more idiomatically, acquired and released. A read/write mutex semaphore (or rwlock in POSIX-speak) is acquired for sharing or acquired for exclusion and released. A Dijkstra semaphore is upped or downed. This is the original usage of the term semaphore in computing. It is largely useless in comparison to the other types of semaphore. -- Regards, Dave [RLU #314465] === david.w.n...@ntlworld.com (David W Noon) === ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Operator overloading
Is there any way of overloading the ^ (dereference) operator for a user-defined type? I'm looking at a simple Prolog interpreter written in TP3, i.e. 16-bit code, and I think I might even have a fun use for it. Obviously it's chock-full of segment:offset pointers but if ^ could be overloaded it might make it easier to implement or at least to debug a local heap. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
