Implemented thread priority as the 'nice' value on Linux. High priority threads require root permissions (you shouldn't give your game root permissions though!)
Patrick Baggett 2011-02-16 22:58:33 PST
This enhancement is for both x86/x64 Windows.
The SDL implementation of mutexes uses the Win32 API interprocess
synchronization primitive called a "Mutex". This implementation is subpar
because it has a much higher overhead than an intraprocess mutex. The exact
technical details are below, but my tests have shown that for reasonably high
contention (10 threads on 4 physical cores), it has 13x higher overhead than
the Win32 CriticalSection API.
If this enhancement is accepted, I will write a patch to implement SDL mutexes
using the critical section API, which should dramatically reduce overhead and
improve scalability.
-- Tech details --
Normally, Win32 Mutexes are used across process boundaries to synchronize
separate processes. In order to lock or unlock them, a user->kernel space
transition is necessary, even in the uncontented case on a single CPU machine.
Win32 CriticalSection objects can only be used within the same process virtual
address space and thus to lock one, does not require a user->kernel space
transition for the uncontended case, and additionally may spin a short while
before going into kernel wait. This small spin allows a thread to obtain the
lock if the mutex is released shortly after the thread starts spinning, in
effect bypassing the overhead of user->kernel space transition which has higher
overhead than the spinning itself.
the pthread implementation of SDL_SemWaitTimeout() uses busy waiting, while
pthread's sem_timedwait() does work. Attached are patches that make use of it
I think this also fixes the bug relating to non-latin characters in filenames, since UNICODE wasn't defined in SDL_rwops.c
--HG--
rename : src/SDL_android.cpp => src/core/android/SDL_android.cpp
rename : src/SDL_android.h => src/core/android/SDL_android.h
Ozkan Sezer 2010-02-06 12:31:06 PST
Hi:
Here are some small fixes for compiling SDL against mingw-w64.
(see http://mingw-w64.sourceforge.net/ . Despite the name, it
supports both win32 and win64.)
src/audio/windx5/directx.h and src/video/windx5/directx.h (both
SDL-1.2 and SDL-1.3.) I get compilation errors about some union
not having a member named u1 and alike, because of other system
headers being included before this one and them already defining
DUMMYUNIONNAME and stuff. This header probably assumes that those
stuff are defined in windef.h, but mingw-w64 headers define them
in _mingw.h. Easily fixed by moving NONAMELESSUNION definition to
the top of the file.
src/thread/win32/SDL_systhread.c (both SDL-1.2 and SDL-1.3.) :
The __GNUC__ case for pfnSDL_CurrentBeginThread is 32-bit centric
because _beginthreadex returns uintptr_t, not unsigned long which
is 32 bits in win64. Changing the return type to uintptr_t fixes
it.
video/SDL_blit.h (and configure.in) (SDL-1.3-only) : MinGW-w64
uses msvcrt version of _aligned_malloc and _aligned_free and
they are defined in intrin.h (similar to VC). Adding proper
ifdefs fixes it. (Notes about macros to check: __MINGW32__ is
defined for both mingw.org and for mingw-w64 for both win32 and
win64, __MINGW64__ is only defined for _WIN64, so __MINGW64__
can't be used to detect mingw-w64: including _mingw.h and then
checking for __MINGW64_VERSION_MAJOR does the trick.)
SDL_win32video.h (SDL-1.3-only) : Tweaked the VINWER definition
and location in order to avoid multiple redefinition warnings.
Hope these are useful. Thanks.
Patrice Mandin
Hello,
I originally added pth support for threads in SDL 1.2 because on the Atari
platform we did not have any thread library.
I think pth support could be removed from SDL 1.3 for two reasons:
- Atari platform removed
- pth does not provides real (preemptive) threads, because it is user space,
and expect the application to call one of its function to give CPU to another
thread. So it is not exactly useful for applications, that expect threads to
run simultaneously.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%404452
The thread ID is an unsigned long so it can hold pthread_t so people can do naughty things with it.
I'm going to be adding additional useful thread API functions, but this should prevent crashes in people's existing code on 64-bit architectures.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%404327
SDL_SemWaitTimeout in src/thread/generic/SDL_syssem.c line 179 (SVN trunk):
--sem->count;
should be
if (retval == 0) {
--sem->count;
}
Without this, sem->count will underflow on timeout effectively breaking the
semaphore. It appears that the implementation has been wrong since the initial
revision.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403844
Betreff: [SDL] [PATCH] Make static variables const
Datum: Tue, 19 May 2009 19:45:37 +0200
Hi,
this is a set of simple changes which make some of SDL's internal static
arrays constant. The purpose is to shrink the number of write-able
static bytes and thus increase the number of memory pages shared between
SDL applications.
The patch set is against trunk@4513. Each of the attached patch files is
specific to a sub-system. The set is completed by a second mail, because
of the list's 40 KiB limit.
The files readelf-r4513.txt and readelf-const-patch.txt where made by
calling 'readelf -S libSDL.so'. They show the difference in ELF sections
without and with the patch. Some numbers measured on my x86-64:
Before
[13] .rodata PROGBITS 00000000000eaaa0 000eaaa0
0000000000008170 0000000000000000 A 0 0 32
[19] .data.rel.ro PROGBITS 00000000003045e0 001045e0
00000000000023d0 0000000000000000 WA 0 0 32
[23] .data PROGBITS 00000000003076e0 001076e0
0000000000004988 0000000000000000 WA 0 0 32
After
[13] .rodata PROGBITS 00000000000eaaa0 000eaaa0
0000000000009a50 0000000000000000 A 0 0 32
[19] .data.rel.ro PROGBITS 0000000000306040 00106040
0000000000002608 0000000000000000 WA 0 0 32
[23] .data PROGBITS 0000000000309360 00109360
0000000000002e88 0000000000000000 WA 0 0 32
The size of the write-able data section decreased considerably. Some
entries became const-after-relocation, while most of its content went
straight into the read-only data section.
Best regards, Thomas
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403618
From: John Bartholomew
Subject: [SDL] SDL Semaphore implementation broken on Windows?
Hi,
Over the past couple of days, I've been battling with SDL, SDL_Mixer and SMPEG to try to find an audio hang bug. I believe I've found the problem, which I think is a race condition inside SDL's semaphore implementation (at least the Windows implementation). The semaphore code uses Windows' built in semaphore functions, but it also maintains a separate count value. This count value is updated with bare increment and decrement operations in SemPost and SemWaitTimeout - no locking primitives to protect them.
In tracking down the apparent audio bug, I found that at some point a semaphore's count value was being decremented to -1, which is clearly not a valid value for it to take.
I'm still not certain exactly what sequence of operations is occuring for this to happen, but I believe that overall it's a race condition between a thread calling SemPost (which increments the count) and the thread on the other end calling SemWait (which decrements it).
I will try to make a test case to verify this, but I'm not sure if I'll be able to (threading errors being difficult to reproduce even in the best circumstances).
However, assuming this is the cause of my problems, there is a very
simple fix:
Windows provides InterlockedIncrement() and InterlockedDecrement()
functions to perform increments and decrements which are guaranteed to be atomic. So the fix is in thread/win32/SDL_syssem.c: replace occurrences of --sem->count with InterlockedDecrement(&sem->count); and replace occurrences of ++sem->count with InterlockedIncrement(&sem->count);
This is using SDL v1.2.12, built with VC++ 2008 Express, running on a
Core 2 duo processor.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403535
Removed SDL_KillThread() from the API, as it isn't safe on many platforms.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403240
