[Bf-committers] Pretty clueless Linux threads crashing...

[Ton Roosendaal]

Hi,

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  
list.
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.

-Ton-


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  
> locking.)
>
> 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;
>> http://www.programmersheaven.com/articles/pathak/article1.htm
>> 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.
>> Thanks,
>> -Ton-
>> On 24 Feb, 2006, at 1:02, Chris Want wrote:
>>> Ton Roosendaal wrote:
>>>
>>>> Hi,
>>>> 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:
>>>> http://www.blender.org/bf/untitled-1.blend
>>>> Not sure if it still crashes, it seems to only happen every 10  
>>>> frames   or so. So just press ANIM on it.
>>>> -Ton-
>>>
>>>
>>> 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.
>>>
>>> Regards,
>>> Chris
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at projects.blender.org
>>> http://projects.blender.org/mailman/listinfo/bf-committers
>>>
>>>
>> ---------------------------------------------------------------------- 
>> -- --
>> Ton Roosendaal  Blender Foundation ton at blender.org   
>> http://www.blender.org
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at projects.blender.org
>> http://projects.blender.org/mailman/listinfo/bf-committers
>
> -- 
> [ e d @ h a l l e y . c c ]
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org