[Bf-committers] Pretty clueless Linux threads crashing...
ton at blender.org
Fri Feb 24 14:21:44 CET 2006
I've carefully already removed all globals from code accessed by
threads (apart from one exception, which is read-only though), and
ensured threads don't write in data they share. The MEM module I had to
protect with mutexes, since allocated blocks are stored in a single
Also image reading is mutexed.
What I've added 'volatile' for is for variables written by threads (in
own local assigned data arena) which is checked by the main thread to
detect if a thread is finished, or how far scanline updating is. These
variables are not altered by the main thread, unless a thread is ready.
The fact Blender runs with threads in background mode (blender -b)
fine, and on OSX fine, and in some linux configs fine... is the most
confusing part. The gdb crashlogs give very weird mixes of SDL code and
pthread code.... which is I think the main reason for problems.
At the moment I consider to drop SDL entirely, and use phtread
directly. That's also used by yafray btw... my impression is that SDL
(S is for Simple!) is mostly used for basic and simple programs, to
quickly get an app running.
On 24 Feb, 2006, at 14:11, Ed Halley wrote:
> The 'volatile' keyword is best used for situations that proper thread
> coding cannot fix: e.g., device drivers which change memory contents
> within the reach of your process without any notification. It's an
> abomination but hardware makers often don't consider software
> engineering constraints.
> The proper way to code threads that access the same variables (reading
> OR writing) is to use the appropriate semaphor/mutex/spinlock
> mechanism provided by your language and platform. It doesn't matter
> if they're global, heaped, stacked or buried within some arcane
> database API. Minimize the number of variables or objects which must
> be read while any thread has the possibility of writing them.
> Consider those variables to be "resources" which must be checked out
> like a library book, and properly lock them during every write and
> every read. (Some people try to get away with locking during reading
> only, but unless you know your platform will write the whole variable
> atomically, it's a recipe for disaster to read things without
> Every shared variable. Every shared object.
> Ton Roosendaal wrote:
>> Hi Chris,
>> Aah! The volatile trick again... I spent some time reading about it,
>> and it seems to be recommended to use especially when coding threads.
>> This is a nice read;
>> I'm still unsure which variables would be the best candidates to
>> become volatile... but I know a couple of important ones that I
>> could try first.
>> On 24 Feb, 2006, at 1:02, Chris Want wrote:
>>> Ton Roosendaal wrote:
>>>> I suspected scanline updating from crashing... it was reported to
>>>> crash less frequent then, but that's not the solution. Apparently
>>>> I've put a little bit too much efforts to limit code for update
>>>> scanlines! So yes, it skips the 2nd thread tile drawing. Will be
>>>> brought back.
>>>> We did tests a couple of days on irc with this .blend:
>>>> Not sure if it still crashes, it seems to only happen every 10
>>>> frames or so. So just press ANIM on it.
>>> I got the crashes too with that file (takes
>>> about 70-90 frames here).
>>> Valgrind was giving me some inconsistent info,
>>> so I start to play with the optimization levels.
>>> I find that if I set the optimization for linux
>>> to -O0 and then touch threads.c and all the stuff
>>> in render/intern/source, then type "make", blender
>>> no longer crashes. At -O1 it still crashes.
>>> Bf-committers mailing list
>>> Bf-committers at projects.blender.org
>> -- --
>> Ton Roosendaal Blender Foundation ton at blender.org
>> Bf-committers mailing list
>> Bf-committers at projects.blender.org
> [ e d @ h a l l e y . c c ]
> Bf-committers mailing list
> Bf-committers at projects.blender.org
Ton Roosendaal Blender Foundation ton at blender.org
More information about the Bf-committers