Bug 13061 - Concurrent access problem in TPL with Monotouch
Summary: Concurrent access problem in TPL with Monotouch
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 6.2.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Marek Safar
Depends on:
Reported: 2013-07-05 04:11 UTC by maik.thomas-radenberg
Modified: 2017-04-25 22:48 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Test project to reproduce the issue (6.00 MB, application/octet-stream)
2013-07-05 04:12 UTC, maik.thomas-radenberg

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description maik.thomas-radenberg 2013-07-05 04:11:48 UTC
we encountered a problem where 2 Threads simultaneously execute:

Task.Factory.StartNew(() => new NSObject().BeginInvokeOnMainThread(...));

What we experience is that the App freezes and the system constantly spawns new Threads (what might be the cause for the freezing). The error is reproducible on the iPhone-Simulator with the attached project. In our real life App the crash is causeb by two web requests which respond simultaneously.

We have a workaround for the problem by using a Mutex, but that only solves the symptom and not the cause of the problem.

Perhaps there is also an error or knowledge gap on our side and there is a reasonable explanation for the behavior. So don´t hesitate to tell us if we are wrong.

Kind regards.
Comment 1 maik.thomas-radenberg 2013-07-05 04:12:56 UTC
Created attachment 4276 [details]
Test project to reproduce the issue
Comment 2 Rolf Bjarne Kvinge [MSFT] 2013-07-05 08:52:59 UTC
I tried the sample and quickly had over 120 threads running.

Marek, is that normal?
Comment 3 Marek Safar 2013-07-05 09:29:49 UTC
The app starts new tasks in a loop. So you can have up to 400 threads running, that's default ThreadPool limit.  It should however reuse existing native threads instead of creating new one every time. How did you detect it's creating a new native thread constantly ?

What is the crash you are getting. That sounds more like some missing locking.

Rolf, 120 is good our GC is getting better ;-)
Comment 4 maik.thomas-radenberg 2013-07-08 03:30:15 UTC
We experienced this behaviour in our App when two Web-Requests triggered their OnResponse-Handler simultaneously. That happens not very often but it is a valid scenario. On the Output-View in Xamarin-Studio we see something like this:
Thread started: <Thread Pool> #xx
where xx counts up very quickly until the App crashes. I will provide a dump of the console output as soon as I can reproduce it in real life.

This behaviour starts exactly after two web requests tried to access the UI-Thread simultaneously (as is simulated in the test project). We do not lock the threads at all since they are only accessing local variables. To post the task to the UI-Thread we use:
new NSObject().BeginInvokeOnMainThread(() => ...)

But the UI-Thread never executes the delegate then (we tried to hit breakpoints in there and also used console output). The system hangs while the thread spawning takes place so the UI-Thread seems to be busy with doing something but it seems that it is not executing our delegates.
Comment 5 maik.thomas-radenberg 2013-07-29 04:35:50 UTC
We assume that the crash happens since the system is running out of handles for the new threads.
Comment 6 PJ 2013-11-19 17:05:55 UTC
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?

If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
Comment 7 maik.thomas-radenberg 2013-11-20 05:17:43 UTC
From our point of view we provided all necessary info to reproduce the problem.
Comment 8 Rolf Bjarne Kvinge [MSFT] 2014-09-22 11:02:13 UTC
I can still reproduce an issue: threads aren't reused, the thread count just goes up and up. I determined this by running the app in the simulator and looking at the Application Output, where threads will be listed when they're created and when they finish: https://gist.github.com/rolfbjarne/8e50ffff2e258b0050a4
Comment 9 Manuel de la Peña [MSFT] 2017-03-22 16:56:34 UTC

The supplied sample is not longer valid. Was the bug fix, if not, please let me know and will reopen it.
Comment 10 Alex Soto [MSFT] 2017-04-25 22:48:08 UTC
We have not received the requested information that Manuel requested. If you are still experiencing this issue please provide all the requested information and re-open the bug report. Thanks!