[M3devel] pthread errors on FreeBSD

[Olaf Wagner]

Quoting Tony Hosking <hosking at cs.purdue.edu>:
> On Jan 5, 2008, at 1:51 PM, Olaf Wagner wrote:
>
>> Hi Tony,
>>
>> I've today run the tests in m3-sys/m3tests (which were never completely
>> adapted to CM3 since my initial import in 2003, I'm afraid), but there
>> are two significant differences between UTHREADS and PTHREADS on
>> FreeBSD.
>>
>> The first is the failure of p005:
>>
>> --- p005 --- a simple thread program
>> --- p0/p005/stdout.pgm  2008-01-05 18:24:25.000000000 +0100
>> +++ ../src/p0/p005/stdout.pgm   2003-03-08 11:14:00.000000000 +0100
>> @@ -1,4 +1,4 @@
>> i = 12
>> -Changing i to 15
>> +Changing i to 19
>> Changing i to 22
>> i = 22
>>
>> This concerns the order in which new threads are started.
>
> Whatever order they are started there is no guarantee they will reach
> acquire the lock in any particular order.
>
>> I'm not
>> sure if this is really specified, or just random; if so, the test
>> should be changed. Programs which make assumptions about the order
>> will of course fail then.
>
> The test needs changing to force a particular order.
>
>> 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