[fpc-pascal] Re: GetAffinity\SetAffinity

Mark ... many thanks. Your last comment prompted me to avoid using Write/Writeln to monitor what was happening. By removing Write/Writeln from the threads , ... everything works correctly with two threads , one running on core1 and the other thread running on core2. I think this boils down to the

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Brian wrote: "... The critical sections you are using only protect each thread against itself, meaning they basically do nothing. Being inside a critical section is not a guarantee that you won't get preempted, but just that no other threads can enter the same section. ..." The two threads do no

[fpc-pascal] Re: GetAffinity\SetAffinity

"... The critical sections you are using only protect each thread against itself, meaning they basically do nothing. Being inside a critical section is not a guarantee that you won't get preempted, but just that no other threads can enter the same section. ..." The two threads do not share and var

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Am 22.11.2013 19:17 schrieb "Jeppe Græsdal Johansen" : > Your code is broken. > > You are using the console output from two threads simultaneously without proper locking. That's most likely what's causing the crash. (Disclaimer: I haven't looked at the code, so I'm just assuming that he's using Wr

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Den 22-11-2013 16:21, Brian skrev: Mark ... sorry for the mixup. The program and unit should now be stand alone. The unit links libc (rev6). Regards Brian coret.pas test_threads.pas

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Brian wrote: Mark ... sorry for the mixup. The program and unit should now be stand alone. The unit links libc (rev6). Regards Brian coret.pas test_threads.pas

[fpc-pascal] Re: GetAffinity\SetAffinity

Attached binary executables which run on Ubuntu 12.04lts , but should be portable. coret_ok sets the process and two threads to core1 coret_fail sets to process to cores1 and 2 , one thread to core 1 and one thread to core 2. It soemtimes runs ok , but usually fails with a GP fault. coret_ok

[fpc-pascal] Re: GetAffinity\SetAffinity

Mark ... sorry for the mixup. The program and unit should now be stand alone. The unit links libc (rev6). Regards Brian coret.pas test_threads.pas

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Brian wrote: Attached is a simple test program with two threads. When the threads run , one displays '+' and the other displays '2'. If both threads run on the same core , the threads work , but if the threads are set to different cores , it generates a GP fault. If anyone is interested , downl

[fpc-pascal] Re: GetAffinity\SetAffinity

Mark , Thanks for the tips and info. There are two reasons for running threads on specific cores : 1) The possible need for a tight loop for receiving serial data. 2) The program is serial in nature receiving data, does not use X11 , controls the mouse and keyboard using libusb , and writes dir

[fpc-pascal] Re: GetAffinity\SetAffinity

Attached is a simple test program with two threads. When the threads run , one displays '+' and the other displays '2'. If both threads run on the same core , the threads work , but if the threads are set to different cores , it generates a GP fault. If anyone is interested , download the code .

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Brian wrote: Mark, All the documentation seems to indicate that processes and threads are treated alike in Linux , Remember that historically, there were two different threading models: LinuxThreads, where a thread was implemented as a process, and the newer NPTL. Somewhere I've got code tha

[fpc-pascal] Re: GetAffinity\SetAffinity

Mark, All the documentation seems to indicate that processes and threads are treated alike in Linux , however , even having established that I can apparently select a core to run a thread , I haven't yet been able to make it work. I explain the findings from a dual core Intel CPU. Using the sche

Re: [fpc-pascal] Re: GetAffinity\SetAffinity

Brian wrote: After a bit of research , the issue of setting the cpu affinity has been solved , which may be of use to other folks. A bit of info here concerning the data type cpu_set_t , which as far as I can determine (no help from the mess that is the c library source) is essentially an array

[fpc-pascal] Re: GetAffinity\SetAffinity

After a bit of research , the issue of setting the cpu affinity has been solved , which may be of use to other folks. A bit of info here concerning the data type cpu_set_t , which as far as I can determine (no help from the mess that is the c library source) is essentially an array of DWORD. For m

[fpc-pascal] Re: GetAffinity\SetAffinity

Request for additional info : do_Syscall(syscall_nr_sched_setaffinity,fpgetpid,setsize,@cpu_set); The function do_SysCall() Arg 4 expects longint not a pointer but even when typecast do_SysyCall() doesn't appear to work. ... a good description here. http://www.ibm.com/developerworks/linux/

[fpc-pascal] Re: GetAffinity\SetAffinity

Alexey Voytsehovich wrote > Just a huge thank you:) > > 2011/1/21 < > michael.vancanneyt@ > >: >> >> >> See >>  man sched_setaffinity >> for the call to do this. >> >> Free Pascal does not have this call predefined, but you can make this >> call. >> >> >> Using the do_syscall you should be able