[Openmcl-devel] Probable Threading Problem (HOWTO request!)

Sun Jan 21 21:27:00 PST 2007

On Sun, 21 Jan 2007, Brent Fulgham wrote:

>
> On Jan 21, 2007, at 7:59 PM, Brent Fulgham wrote:
>
>> It seems like I need some kind of thread concurrency problem that
>> needs some mechanism for controlling which threads are allowed to
>> access the GL context.  I don't know if the original MCL provided
>> this mechanism behind the scenes, but the same code that works fine
>> under MCL 5.1 results in this nasty crash under OpenMCL 1.1 (as of
>> this past Friday's update).
>
> As usual, formulating my question into an e-mail forced me to review
> everything carefully (to anticipate people's questions).
>
> By adding some locking primitives, I was able to completely correct
> the problem.
>
> Gary, OpenMCL rocks!

In MCL, a thread context switch could only occur at certain points
(on entry to a function or at the top of a loop; it couldn't happen
in the middle of foreign code execution.)  There was lots
of code that knew that, and there was lots of MCL code that really
should have been using locks but was getting away with not doing
so because of the way that the scheduler worked.

There are also some Cocoa and OpenGL issues to be aware of.  Apple
has a web page or two that describes these issues, such as:

<http://developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_threading/chapter_12_section_3.html>

The good news is that the issues that you'd run into when doing
multithreaded OpengGL stuff in C/ObjC are essentially the same
as those you'd face when doing it in OpenMCL.

The bad news is that the issues were very different for MCL, and just
about any multithreaded code written for "cooperatively" scheduled
threads needs to be carefully reviewed to run with preemptively
scheduled threads.  A typical outcome of that review is to introduce
locking in places that were getting away without it.

Locking primitives introduce some overhead.  It's a lot of overhead
in some contexts (compared to the cost of getting a character out
of a stream buffer) and probably pretty minimal in other cases
(compared to the cost of screen drawing or other I/O.)  As locking
primitives go, OpenMCL's are fairly cheap (the OS isn't involved
unless there's contention), and too much locking (maybe a performance
hit) is usually a lot better than not enough (crashes and other
misbehavior.)