Clarify various questions about threads in our docs #809

Closed
leto opened this Issue Aug 9, 2012 · 6 comments

Comments

Projects
None yet
4 participants
Owner

leto commented Aug 9, 2012

It has been mentioned on the parrot-dev list that there is a dirth of info on our new threads implementation.

We should at least port the docs mentioned below into a useful and findable place in the Parrot documentation. Where should that be?

http://niner.name/Hybrid_Threads_for_the_Parrot_VM.pdf chapter 7 (page 29-31)

Contributor

cotto commented Nov 9, 2012

Some of the files mentioned in the thesis are in his branch. We should clean them up and steal them once threads are in master. @niner, if you still have the source for your thesis lying around, it'd be nice to have as a starting point for developer documentation and examples.

Contributor

niner commented Nov 9, 2012

On Friday 09 November 2012 03:01:29 cotto wrote:

Some of the files mentioned in the thesis are in his
branch.
We should clean them up and steal them once threads are in master.
@niner, if you still have the source for your thesis lying around, it'd be
nice to have as a starting point for developer documentation and examples.

Just pushed them to:
https://github.com/niner/HybridThreads

I wonder: which files did you only find in this branch? I thought, I put
everything relevant into threads.

Stefan

Contributor

cotto commented Nov 9, 2012

Thanks! I didn't realize that your examples were already in the branch. That'll be a big help.

Member

rurban commented Dec 4, 2012

Docs: Updated pdd25_concurrency.pod with links to the new green threads and hybrid threads explanations in 0396004 and 0bc6d9f

We still need to add documentation how and how not to access shared data, and how the Proxy PMC interfers with the GC

#parrot11:
diakopter: does the GC scan other threads' memory areas for references to its own objects?
diakopter: (or traverse the other threads' live objects graph or whatever)
diakopter: in the thesis pdf, the implied answer is no.
cotto: That's the impression I got too, but I haven't tested it.
diakopter: so my question is, what if another thread owns the object that has the only reference to an object?
diakopter: does this mean the GC can collect objects early/spuriously?
diakopter: (yes, if it doesn't scan other threads)
diakopter: but since (as stated in the thesis pdf) other threads can be running while one thread's GC runs, that GC could miss an object while its only reference is moved from the area the GC hasn't scanned yet to the area it's already scanned.
diakopter: (if it actually does try to scan other threads)
diakopter: (or while the only reference to the object is in another CPU's register only)
diakopter: (regardless of the scanning technique (traverse or linear scan), the point still holds)
diakopter: the only reference can be moved on the graph while it's being traversed.
cotto: let me check something
diakopter: my point is that either way (whether it scans other threads' stuff or not), it has the potential to miss references if other threads are allowed to run while it runs.
diakopter: .. and this is one thing the thesis makes very clear: that it is intended for other threads to run concurrently with the GC.
cotto: The solution seems to be that the Task holds a reference to shared objects.
diakopter: right, but what about when there is no Task pending
diakopter: surely it doesn't keep around all billion Tasks that could have run
cotto: The reference will exist until the Task is destroyed, even if it's not executing anything at the moment.
diakopter: so threads cannot hold onto references to objects from other threads between requesting Tasks to be run?
diakopter: it's implied that, being a queue, Tasks go away after being executed
diakopter: (where else would they hang around)
cotto: My impression is that Tasks are more like workers in that they don't get destroyed implicitly and that the parent can reuse them when needed. Let me see if I can verify that,
diakopter: Tasks are requests from a child thread to the main thread or from the main thread to one of its child threads to perform a write operation on an object in the other thread
diakopter: only the main thread can spawn other threads.
diakopter: child threads cannot access/modify objects in each other.
diakopter: it doesn't say anything about parents reusing Tasks (what would it use them for?) requests to other threads?

diakopter: it says all read access must go through proxies which create read Tasks on the owner thread. If a write operation is occuring, but is preempted by a read operation, can it read the object in an inconsistent state, if the user implemented the data structure in user code (PIR or whatever)?
diakopter: the only ways I can think to mitigate this are to 1. not implement data structures that expect consistency during reads 2. use C for the write operations (since it only preempts on Branch) 3. use wait-free algorithms to make it fully threadsafe 4. can't use locks because of the potential for deadlock
diakopter: in any case, preventing the normal case (user implementing a data structure in user code)
diakopter: two other more specific cases of the "only reference elsewhere" question: if the only reference exists solely in another CPU's register 2. if the only reeference exists in the Task queue of another thread, which would require obtaining a lock on all the other threads' task queues, to not miss cross-writes)

plus jonathans GC questions: http://irclog.perlgeek.de/perl6/2012-12-03#i_6209348
#perl6:
23:30 jnthn rurban: If I solve things just by digging through the proxy to the underlying object, what happens?
23:30 jnthn rurban: That is, if the object is manipulated from another thread?
23:30 rurban read-only access should be fine.
23:31 read-write forbidden
23:31 for write we would need a mutex
...
23:33 jnthn rurban: How's the GC handling the multiple threads?
23:33 jnthn rurban: I mean, is the problem with writes mostly connected to that?

And http://irclog.perlgeek.de/perl6/2012-12-03#i_6209408
jnthn rurban: If you have thread A owning the object that has the only reference to an object owned by thread B
23:47 And thread A reads the reference into, say, a register and nulls it
23:47 And then thread B runs its GC
23:47 How does it know not to collect the object?

@rurban rurban added this to the 7.0.0 milestone Nov 17, 2014

Member

rurban commented Nov 18, 2014

Checked the content of docs/pdds/pdd25_concurrency.pod, it's good.

@rurban rurban closed this Nov 18, 2014

Member

rurban commented Nov 19, 2014

Added a bit about our thread-pool in 02b40b1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment