[M3devel] pthread errors on FreeBSD

[Tony Hosking]

Let me look into this one...

On Jan 8, 2008, at 5:57 PM, Olaf Wagner wrote:

> Quoting Tony Hosking <hosking at cs.purdue.edu>:
>> On Jan 5, 2008, at 1:51 PM, Olaf Wagner wrote:
>>
>>> The second failure shows up in p007, where `a whole bunch of  
>>> threads'
>>> is started:
>>> +++ ../src/p0/p007/stderr.pgm   2003-03-08 11:14:01.000000000 +0100
>>> @@ -218,11 +218,1798 @@
>>>   218: 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218
>>>   219: 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219
>>>   220: 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220
>>> -  221:
>>> -
>>> -***
>>> -*** runtime error:
>>> -***    Thread client error: Release failed with error: 1
>>> -***    file "ThreadPThread.m3", line 174
>>> -***
>>> -
>>> +  221: 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221
>>> +  222: 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222
>>> +  223: 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223
>>> +  224: 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224
>>> +  225: 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225
>>> +  226: 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226
>>> +  227: 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227
>>> +  228: 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228
>>> +  229: 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229
>>> +  230: 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230
>>> +  231: 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231
>>> +  232: 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232
>>> +  233: 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233
>>> +  234: 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234
>>> +  235: 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235
>>> +  236: 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236
>>>
>>> Here a thread crashes when trying to unlock a mutex with EPERM,
>>> which I do not really understand. man errno says:
>>
>> I am unable to reproduce this on my I386_DARWIN machine.  EPERM is  
>> the
>> error given if the thread trying to release the mutex does not  
>> actually
>> hold it.  However, the ThreadPThread is already checking to make sure
>> the lock is held by the releasing thread, in this case claiming that
>> the thread *does* hold the lock.  So, I suspect the EPERM error is a
>> result of some other problem, though I don't know what based on the
>> output you are showing.  I wonder if you have encountered some system
>> limit.
>
> This seems to be caused by using the ThreadF interface to suspend
> other threads. If a mutex is used, the test passes:
>
> PROCEDURE Txt (t: TEXT) =
>   BEGIN
>     (* ThreadF.SuspendOthers (); *)
>     LOCK iolock DO
>       RTIO.PutText (t);
>     END;
>     (* ThreadF.ResumeOthers (); *)
>   END Txt;
>
> Apart from the fact that a mutex is the correct thing to use,
> have you any idea why ThreadF procedures fail? It makes me a bit
> nervous, as they are used by the garbage collector, aren't they?
>
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin,  
> Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23  
> 45 86 95
>    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:  
> Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:  
> DE163214194
>