pthreads and MSL

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Patrick Girard - 17 Jul 2003 14:24 GMT

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

Reply to this Message

MW Ron - 17 Jul 2003 16:16 GMT

>Hello,
>
[quoted text clipped - 3 lines]
>I must admit I am very confused by this. So if anyone managed to do the
>same without problems let me know.

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

Signature

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 - MWRon@metrowerks.com - http://www.metrowerks.com

Reply to this Message

Patrick Girard - 17 Jul 2003 17:20 GMT

> >Hello,
> >
[quoted text clipped - 13 lines]
>
> Ron

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?

Reply to this Message

Paul Guyot - 17 Jul 2003 21:43 GMT

> 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://developer.apple.com/documentation/Carbon/Conceptual/Multitasking_Mult
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

Signature

Philosophie de baignoire - consultations sur rendez-vous.

NPDS: http://newton.kallisys.net:8080/
Apache: http://www.kallisys.com/

Reply to this Message

Sean McBride - 17 Jul 2003 23:05 GMT

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

That flag is on for Mach-O.

Reply to this Message

Patrick Girard - 17 Jul 2003 23:32 GMT

> > Could you be more precise with file i/o? For file access i use the
> > FileManager
[quoted text clipped - 9 lines]
> So you'd better check the APIs. For the File Manager and Carbon APIs, you
> can look here:

http://developer.apple.com/documentation/Carbon/Conceptual/Multitasking_Mult

> iproServ/appendixa/index.html
>
[quoted text clipped - 6 lines]
>
> Paul

If i use mutex locks to insure thread safetiness, is it enough?

> NPDS: http://newton.kallisys.net:8080/
> Apache: http://www.kallisys.com/

Reply to this Message

Paul Guyot - 18 Jul 2003 18:12 GMT

> 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

Signature

Philosophie de baignoire - consultations sur rendez-vous.

NPDS: http://newton.kallisys.net:8080/
Apache: http://www.kallisys.com/

Reply to this Message

Thorrsten Froehlich - 18 Jul 2003 18:14 GMT

> In article (Dans l'article) <Q1ARa.42777$PD3.4407912@nnrp1.uunet.ca>,
> "Patrick Girard" <pgirard@ubisoft.qc.ca> wrote (écrivait) :
[quoted text clipped - 5 lines]
> I think I read somewhere that more and more functions were thread safe but
> Apple doesn't publish actualized lists AFAIK.

(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

>From: George Warner <geowar@snip>
>To: <carbon-development@snip>
[quoted text clipped - 5 lines]
>> I noticed that for gestaltMPCallableAPIsAttr the attribute
>> gestaltMPTrapCalls is set on Mac OS 9.2.2 (CarbonLib 1.5).

According to the

>> "documentation", the Gestalt.h header file to be precise,

gestaltMPTrapCalls

>> is "True if most trap-based calls can be made from MPTasks".
>>
>> Does this imply most of the toolbox? The term "trap-based calls"

makes

>> sense to me only in the context of the 68K toolbox which used

traps, so I am

>> a bit confused about the true meaning in this context.

Unfortunately there

>> is no further documentation available about gestaltMPTrapCalls...
>
[quoted text clipped - 15 lines]
> Mixed Mode Magic Fragment Scientist
> Apple Developer Technical Support (DTS)

Reply to this Message

Sean McBride - 17 Jul 2003 23:05 GMT

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

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

Reply to this Message

Andy Dent - 18 Jul 2003 18:26 GMT

G'day Patrick

> 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?

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.

Reply to this Message

Mac Forum / Programming / CodeWarrior / July 2003

pthreads and MSL