r - Apparent time-travelling via python's multiprocessing module: surely I've done something wrong -
i use python video-game-like experiments in cognitive science. i'm testing out device detects eye movements via eog, , device talks computer via usb. ensure data being continuously read usb while experiment other things (like changing display, etc), thought i'd use multiprocessing module (with multicore computer of course), put usb reading work in separate worker process, , use queue tell worker when events of interest occur in experiment. however, i've encountered strange behaviour such when there 1 second between enqueuing of 2 different messages worker, when @ worker's output @ end, seems have received second after first. surely i've coded awry, can't see what, i'd appreciate can provide.
i've attempted strip down code minimal example demonstrating behaviour. if go gist:
https://gist.github.com/914070
you find "multiprocessing_timetravel.py", codes example, , "analysis.r", analyzes "temp.txt" file results running "multiprocessing_timetravel.py". "analysis.r" written in r , requires have plyr library installed, i've included example of analysis output in "analysis_results.txt" file @ gist.
despite working multiprocessing, queue still uses synchronization objects (two locks , semaphore) , put method spawns thread (based on 2.7 source). gil contention (and other fun stuff) may come play, suggested blueraja. can try playing sys.checkinterval , see if decreasing decreases observed discrepancy, although don't want run in condition.
note that, if usb reading code drops gil (e.g. ctypes code, or python extension module designed drop gil), true multithreading, , threaded approach might more productive using multiprocessing.
Comments
Post a Comment