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

[Ed Halley]

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 ]