pthreads and MSL

pthreads and MSL

Post by Patrick Gi » Fri, 18 Jul 2003 22:24:39


Hello,

I just ported a lib to MAC OSX using CW 8.3. I use MSL and pthreads
and it seems to work fine...the problem is I heard it wasnt possible to use
both with CW8.3...so why is it working? should i be looking for problems?
I must admit I am very confused by this. So if anyone managed to do the
same without problems let me know.

Thanks!

Patrick
 
 
 

pthreads and MSL

Post by MW Ro » Sat, 19 Jul 2003 00:16:07

In article <HsxRa.42715$ XXXX@XXXXX.COM >,



I think if you use <pthread.h> they should build and link the problems
may be if you have MSL i/o it may not be buffered at the same time.

For sure we will have this in MSL in CW 9. There is nothing "evil"
about mixing MSL and the POSIX from BSD C as long as you don't get the
wrong headers or have problems with file buffering and other i/o
differences.

Ron

--
Metrowerks has moved, our new address is now
7700 West Parmer Lane
Austin, TX 78729
Sales and Support 512-996-5300 800-377-5416
Ron Liechty - XXXX@XXXXX.COM - http://www.yqcomputer.com/

 
 
 

pthreads and MSL

Post by Patrick Gi » Sat, 19 Jul 2003 01:20:49


use
Could you be more precise with file i/o? For file access i use the
FileManager
ugly FSRefs(and friends) so is this safe? I have a couple of unit tests and
they
all run flawlessly. Can I assume that everything is right?

Another question i have. Concerning the MSL version of strcmp. Comparing
char a[] = "test";
char b[] = "testlongerstring";

with the strcmp of MSL the two strings are considered equal. Does the
standard
approve this?
 
 
 

pthreads and MSL

Post by Paul Guyo » Sat, 19 Jul 2003 05:43:52

In article (Dans l'article) <Q1ARa.42777$ XXXX@XXXXX.COM >,
"Patrick Girard" < XXXX@XXXXX.COM > wrote (rivait)
>> Could you be more precise with file i/o? For file access i use the >> FileManager >> ugly FSRefs(and friends) so is this safe? I have a couple of unit tests and >> they >> all run flawlessly. Can I assume that everything is right?

The problem is the thread safety of APIs.

Large parts of the Carbon APIs and the Cocoa APIs, and some POSIX APIs are
not thread safe.

So you'd better check the APIs. For the File Manager and Carbon APIs, you
can look here:
http://www.yqcomputer.com/
iproServ/appendixa/index.html

I think I read somewhere that more and more functions were thread safe but
Apple doesn't publish actualized lists AFAIK.

Concerning the MSL, I read in this group that you need to compile it with a
proper flag because some shared accesses are not protected by a mutex by
default for performance reasons.

Paul

--
Philosophie de baignoire - consultations sur rendez-vous.

NPDS: http://www.yqcomputer.com/ :8080/
Apache: http://www.yqcomputer.com/
 
 
 

pthreads and MSL

Post by Sean McBri » Sat, 19 Jul 2003 07:05:06

In article < XXXX@XXXXX.COM >,



That flag is on for Mach-O.
 
 
 

pthreads and MSL

Post by Sean McBri » Sat, 19 Jul 2003 07:05:41

In article <HsxRa.42715$ XXXX@XXXXX.COM >,



You've probably thinking of the fact that you need to use extern "C"
around the pthread.h include with C++.
 
 
 

pthreads and MSL

Post by Patrick Gi » Sat, 19 Jul 2003 07:32:43


and
http://www.yqcomputer.com/
a
If i use mutex locks to insure thread safetiness, is it enough?
 
 
 

pthreads and MSL

Post by Patrick Gi » Sat, 19 Jul 2003 21:52:01


to
problems?
the
and
Did you do the strcmp under Mac or windows? ...let me find the source of the
method

int strcmp(const char* str1, const char* str2)
{
const unsigned char* p1 = (unsigned char*)str1 - 1;
const unsigned char* p2 = (unsigned char*)str2 - 1;
unsigned long c1, c2;

while( (c1 = *++p1) == (c2 = *++p2))
if(!c1)
return 0;

return(c1 - c2);
}

This method is in MSL_C/MSL_Common/Src/string.c
and clearly if str1 is shorter then str2, strcmp will return 0.

str 1 = "test"
str 2 = "testlonger"

if(!c1) <---- theres the problem
return 0; // means they are equal...but also means that str1 is
shorter....
 
 
 

pthreads and MSL

Post by Carsten Ha » Sun, 20 Jul 2003 00:07:10


the

int strcmp(const char* str1, const char* str2)
{
const unsigned char* p1 = (unsigned char*)str1 - 1;
const unsigned char* p2 = (unsigned char*)str2 - 1;
unsigned long c1, c2;

while( (c1 = *++p1) == (c2 = *++p2))
{
/* invariant: c1 == c2 */

/* test if c1 == 0 (end of string) */
/* because of the invariant it is equivalent to */
/* if (!c1 && !c2) */
/* i.e. we only return 0 if the */
/* two strings have the same length */
/* (and all the previous characters satisfied */
/* the invariant) */
if(!c1)
return 0;
}

/* invariant false, i.e. c1 != c2 */
/* if c1 == 0, return negative number */
/* if c2 == 0, return positive number */
/* in general return negative if c1 < c2, */
/* otherwise positive */
return(c1 - c2);
}

Carsten Hansen
 
 
 

pthreads and MSL

Post by Gabriel Be » Sun, 20 Jul 2003 00:10:29

In article <34SRa.43053$ XXXX@XXXXX.COM >,




The lines are only evaluated if c1 == c2


The MSL code is correct (btw, this is not the ppc version, a more
optimized version is used).

gabB
 
 
 

pthreads and MSL

Post by MW Ro » Sun, 20 Jul 2003 01:43:03

In article <34SRa.43053$ XXXX@XXXXX.COM >,


Both work



This one got to me when I first looked at it too and I was suspect but
let me break it down At first glance it appears like

while( (c1 = *++p1) == (c2 = *++p2))
{
}
if(!c1) return 0;
return(c1 - c2);


but it isn't it is....

while( (c1 = *++p1) == (c2 = *++p2))
{
if(!c1) return 0;
}
return(c1 - c2);

See now, it loops as long as c1 and c2 ARE THE SAME
it checks if it has hit NULL if so it ends and returns zero otherwise
is loops again

if they are not the same, i.e c1 is null and c2 is 'L' it does not
enter the body of the loop and it goes on and returns the difference.

Ron









--
Metrowerks has moved, our new address is now
7700 West Parmer Lane
Austin, TX 78729
Sales and Support 512-996-5300 800-377-5416
Ron Liechty - XXXX@XXXXX.COM - http://www.yqcomputer.com/
 
 
 

pthreads and MSL

Post by Paul Guyo » Sun, 20 Jul 2003 02:12:15

In article (Dans l'article) <wuFRa.42875$ XXXX@XXXXX.COM >,
"Patrick Girard" < XXXX@XXXXX.COM > wrote (rivait)
>> If i use mutex locks to insure thread safetiness, is it enough?

Well, if you protect all your calls to thread unsafe routines with a mutex,
of course it is enough.

But sometimes it is easier to actually design your code in such a way that
all thread unsafe routines are only called within a single (the main)
thread.

Paul

--
Philosophie de baignoire - consultations sur rendez-vous.

NPDS: http://www.yqcomputer.com/ :8080/
Apache: http://www.yqcomputer.com/
 
 
 

pthreads and MSL

Post by froeth » Sun, 20 Jul 2003 02:14:33


(Sorry for replying to the wrong post, but this one isn't visible in
Google yet)

Indeed, theer are many, many more functions thread safe in Carbon, and
almost all are thread-safe. The secret is gestaltMPCallableAPIsAttr
attribute gestaltMPTrapCalls. It isn't really documented, but below is
what I got when asking on the Apple carbon-development mailing list.

I would suggest to ask there specifically about Mac OS X, and maybe
you get an answer that helps. BTW, note that some newer gestalts
don't seem to exist in all versions of Mac OS X but some of Mac OS
9/Carbon, so checking this particular gestalt may not work as expected
- in any case, I never tried checking it under Mac OS X so far...

Thorsten


According to the
gestaltMPTrapCalls
makes
traps, so I am
Unfortunately there
 
 
 

pthreads and MSL

Post by Andy Den » Sun, 20 Jul 2003 02:26:17

In article <HsxRa.42715$ XXXX@XXXXX.COM >,


G'day Patrick


I've been working for months on a suite of programs making heavy use of
threads (Windows, PocketPC and OSX - MachO build).

The only issues I've encountered or read about are:
1) thread output to SIOUX appears to be buffered - only a problem in
some unit tests (causes interesting delayed cleanup issues when strings
passed to printf have been deleted). This may be a bug in my test code,
I'm still not 100% sure.

2) there's a flag for the ANSI string that protects refcount updating
with a mutex - it's disabled by default - look for _MSL_MULTITHREAD or
_MSL_THREADSAFE

I've done a lot of research (trying to solve 1) so I'm pretty confident
that the string issue mentioned above is the ONLY MSL issue with
pthreads.