nathanm@hpcvlx.cv.hp.com (Nathan K. Meyers) (11/22/89)
Could someone please dispel my ignorance on the purpose of a couple of Mach cthread calls? I'm in the dark on the purpose/function of cthread_set_data() and cthread_data() calls. What does it mean to "associate" data with a thread? Some brief samples of how these calls are used would also help. Response by mail preferred -- I'll post any received knowledge if there's sufficient curiosity. Nathan Meyers nathanm@cv.hp.com
nathanm@hpcvlx.cv.hp.com (Nathan K. Meyers) (11/28/89)
Thanks to those who responded. My question is answered. Nathan Meyers nathanm@cv.hp.com
nathanm@hpcvlx.cv.hp.com (Nathan K. Meyers) (11/28/89)
And now that my question has been answered, I'm starting to get the "I'd like to know also" messages. So here's a cc of the clearest explanation I got: > Think of it as ways to store and access data from an arry > indexed by the thread ID. > > Something like > > void* per_thread_data[MAX_THREAD_ID]; > > per_thread_data[thread_id]=x; > /* equiv to cthread_set_data(thread_id,x); > x=per_thread_data[thread_id]; > /* equiv to x=cthread_data(thread_id); > > would achieve the same thing if thread_ids were consecutive. > It's useful in that it is a neat way to get a handle with which > to create your own per-thread data structures. Thanks to Arul A. Menezes for the clear explanation. My big problem in understanding the explanation of these calls in the 1988 Cooper/Draves paper was trying to figure out how these simple semantics allowed you to associate an arbitrary collection of data with a thread. The answer, of course, is that you can associate a single pointer with the thread -- and hang whatever you want off of the pointer. Nathan Meyers nathanm@cv.hp.com
ken@gvax.cs.cornell.edu (Ken Birman) (11/28/89)
In article <113980003@hpcvlx.cv.hp.com> nathanm@hpcvlx.cv.hp.com (Nathan K. Meyers) writes: >My big problem in understanding the explanation of these calls in the >1988 Cooper/Draves paper was trying to figure out how these simple >semantics allowed you to associate an arbitrary collection of data with >a thread. The answer, of course, is that you can associate a single >pointer with the thread -- and hang whatever you want off of the >pointer. > Actually, I also have problems with this aspect of Cthreads. My concern is that if a library needs to associate data with a task, the message seems to be that it should use this facility. But, if, say, ISIS follows this rule, and CAMELOT does too, they will clobber each other. Personally, I think this may be a case of semantics that are just a little too simple to be useful..... Ken Birman
Richard.Draves@CS.CMU.EDU (11/28/89)
Ken Birman makes a good point when he notes that libraries can't safely use the cthread calls to associate data with a thread. I can't speak for Eric, but I think having a simple way to associate data with a thread is better than nothing: it keeps simple programs simple. A complicated library will have to fall back on using its own mechanisms (ie, hash table) to associate data with a thread, which it would have had to do anyway if cthreads didn't provide this mechanism. This is a pretty general problem. For example, a task has only one notify port, and if different libraries try to receive notifications from it they will interfere with each other. Rich
ken@gvax.cs.cornell.edu (Ken Birman) (11/28/89)
In article <4ZQVTxC00hYP4whmM2@cs.cmu.edu> Richard.Draves@CS.CMU.EDU writes: >This is a pretty general problem.... Eric opted for simplicity... Well, I don't know that I find this completely convincing. Just to point it out, you could have some sort of index associated with the per-thread data, e.g. making the rule that index values > 0 are for the application and < 0 for libraries; ISIS could then reserve a block of these, CAMELOT could, etc. The deal could even be dynamic as with INET ports: specify index=0 and we pick an unused value and return it for future use. So, I think this _could_ be solved, even if Eric favored a less complex solution. As for notify ports -- well, I see that as less of an issue because a library can always create an extra task to hang around waiting for notify messages and handle them -- on some port of its own. Ken Ken
dcm@baldur.dell.com (Dave McCracken) (11/28/89)
> > This is a pretty general problem. For example, a task has only one > notify port, and if different libraries try to receive notifications > from it they will interfere with each other. This problem has been solved in the 1003.4 (POSIX) pthreads proposal. This proposal is very similar to cthreads, but the cthread_set_data and cthread_data calls have been expanded to include a key. There is a call to create the key, which would be made by the initial thread, then all subsequent references by any thread would use it. The metaphor for this is a two-dimensional array, with one dimension the key (the library making the call), and the other dimension the thread id. Dave McCracken Dell Computer dcm@dell.dell.com 9505 Arboretum Blvd (512) 343-3720 Austin, TX 78759-7299
Rick.Rashid@CS.CMU.EDU (11/28/89)
Since Ken and Rich are essentially agreeing, let me agree too. cthread_data cannot be used by libraries. A library package would/should handle its own thread specific data using cthread_self() as a way to distinguish cthreads.