summaryrefslogtreecommitdiff
path: root/src/thread
AgeCommit message (Collapse)Author
2014-12-24(svn r27092) -Fix/Add [FS#6186]: Compilation on OS/2 (smedles)frosch
2014-04-23(svn r26482) -Codechange: add an include that allows us to undefine/redefine ↵rubidium
"unsafe" functions to prevent them from being used, and thus having to care about certain aspects of their return values
2014-02-18(svn r26353) -Fix (r26349) [FS#5917]: Win32 and OS/2 ↵frosch
ThreadMutex::WaitForSignal always asserted.
2014-02-16(svn r26350) -Fix (r26349): Silly bugs are silly.frosch
2014-02-16(svn r26349) -Add: Optional recursive locking of mutexes.frosch
2014-02-16(svn r26342) -Add: A mutex locker class.fonsinchen
2013-01-08(svn r24900) -Fix [FS#5389]: Comments with typos (most fixes supplied by ↵planetmaker
Eagle_rainbow)
2011-12-10(svn r23481) -Add: Function to get the CPU core count.michi_cc
2011-05-01(svn r22405) -Document: some more "random-ish" tidbitsrubidium
2010-10-01(svn r20860) -Cleanup: remove some unused functions and variablessmatz
2010-09-17(svn r20823) -Codechange: enable/add some error/sanity checking in the ↵rubidium
pthread code
2009-12-29(svn r18656) -Feature: Add event semaphore support for OS/2orudge
2009-10-15(svn r17776) -Codechange: [SDL] make "update the video card"-process ↵rubidium
asynchronious. Profiling with gprof etc. hasn't shown us that DrawSurfaceToScreen takes a significant amount of CPU; only using TIC/TOC it became apparant that it was a heavy CPU-cycle user or that it was waiting for something. The benefit of making this function asynchronious ranges from 2%-25% (real time) during fast forward on dual core/hyperthreading-enabled CPUs; 8bpp improvements are, in my test cases, significantly smaller than 32bpp improvements. On single core non-hyperthreading-enabled CPUs the extra locking/scheduling costs up to 1% extra realtime in fast forward. You can use -v sdl:no_threads to disable threading and undo this loss. During normal non-fast-forwarded games the benefit/costs are negligable except when the gameloop takes more than about 90% of the time of a tick. Note that allegro's performance does not improve with this system, likely due to their way of getting data to the video card. It is not implemented for the OS X/Windows video backends, unless (ofcourse) SDL is used there. Funny is that the performance of the 32bpp(-anim) blitter is, at least in some test cases, significantly faster (more than 10%) than the 8bpp(-optimized) blitter when looking at real time in fast forward on a dual core CPU; it was slower. The idea comes from a paper/report by Idar Borlaug and Knut Imar Hagen.
2009-09-01(svn r17339) -Codechange: move thread related files to their own directory ↵rubidium
(like done for video, music, sound, etc)