Comments on: The Most Overused Word in Parallel Programming: Reentrancy http://www.thinkingparallel.com/2007/06/08/the-most-overused-word-in-parallel-programming-reentrancy/ A Blog on Parallel Programming and Concurrency by Michael Suess Wed, 09 Jul 2008 02:36:07 +0000 http://wordpress.org/?v=2.5 By: Alejo http://www.thinkingparallel.com/2007/06/08/the-most-overused-word-in-parallel-programming-reentrancy/#comment-12113 Alejo Sat, 09 Jun 2007 14:18:00 +0000 http://www.thinkingparallel.com/2007/06/08/the-most-overused-word-in-parallel-programming-reentrancy/#comment-12113 Reentrant in the sense of Idempotent? http://en.wikipedia.org/wiki/Idempotence In mathematics and computer science, the concept of idempotence (IPA: [ˈaɪdɪmpoʊtəns]) arises in a number of places in abstract algebra (in particular, in the theory of projectors, closure operators and functional programming (in which it is connected to the property of referential transparency). Roughly, if an operation is idempotent, then multiple applications of that operation will yield the same result. Reentrant in the sense of Idempotent?

http://en.wikipedia.org/wiki/Idempotence

In mathematics and computer science, the concept of idempotence (IPA: [ˈaɪdɪmpoʊtəns]) arises in a number of places in abstract algebra (in particular, in the theory of projectors, closure operators and functional programming (in which it is connected to the property of referential transparency). Roughly, if an operation is idempotent, then multiple applications of that operation will yield the same result.

]]> By: Michael Suess http://www.thinkingparallel.com/2007/06/08/the-most-overused-word-in-parallel-programming-reentrancy/#comment-12112 Michael Suess Sat, 09 Jun 2007 14:14:23 +0000 http://www.thinkingparallel.com/2007/06/08/the-most-overused-word-in-parallel-programming-reentrancy/#comment-12112 @Bart: I agree with your analysis. But why use the same word to describe all of this?? Regarding Beijing: Get a good tour guide (I liked the one from Lonely Planet) and spend some time with it before you go into the city searching for spots that you may like. Take a taxi to the location, as they are cheap and then you don't need to read the chinese characters to find anything. If you are a little more adventurous take the subway - they have English signs in there now. Remember to always take a buisness card of the hotel with you that has the name and address written on it in chinese, as almost nobody here speaks English - just in case you get lost (you can always take a taxi back home then - they are everywhere). Practice your barganing skills, as almost everything here can be had for a fraction of the initial price offered. And last but not least: prepare for the heat and the smog, as the air in Beijing is thick, hot and moist at this time of the year. Hope it helps and have fun here! @Bart: I agree with your analysis. But why use the same word to describe all of this??

Regarding Beijing: Get a good tour guide (I liked the one from Lonely Planet) and spend some time with it before you go into the city searching for spots that you may like. Take a taxi to the location, as they are cheap and then you don’t need to read the chinese characters to find anything. If you are a little more adventurous take the subway - they have English signs in there now. Remember to always take a buisness card of the hotel with you that has the name and address written on it in chinese, as almost nobody here speaks English - just in case you get lost (you can always take a taxi back home then - they are everywhere). Practice your barganing skills, as almost everything here can be had for a fraction of the initial price offered.

And last but not least: prepare for the heat and the smog, as the air in Beijing is thick, hot and moist at this time of the year. Hope it helps and have fun here!

]]> By: Bart Samwel http://www.thinkingparallel.com/2007/06/08/the-most-overused-word-in-parallel-programming-reentrancy/#comment-12048 Bart Samwel Fri, 08 Jun 2007 21:26:09 +0000 http://www.thinkingparallel.com/2007/06/08/the-most-overused-word-in-parallel-programming-reentrancy/#comment-12048 I think there are two separate issues here: safe for recursion and safe for multithreading. I can easily think of something that is not safe for recursion but that is safe for multithreading (i.e., a function that uses nonreentrant locks). I can also easily think of something that is safe for recursion but not for multithreading. Reentrancy can be used to describe only "safe for recursion" (in a single-threaded context), only "safe for multithreading" (in a context where recursion simply cannot happen), or both. I think the Butenhof definition is especially vague, it specifies a method for achieving the "safe for multithreading" guarantee, not the guarantee itself. And the method itself somewhat implies "safe for recursion", but it isn't explicitly stated. Any tips for Beijing BTW? I'm flying there tomorrow to go to PODS 2007... I think there are two separate issues here: safe for recursion and safe for multithreading. I can easily think of something that is not safe for recursion but that is safe for multithreading (i.e., a function that uses nonreentrant locks). I can also easily think of something that is safe for recursion but not for multithreading. Reentrancy can be used to describe only “safe for recursion” (in a single-threaded context), only “safe for multithreading” (in a context where recursion simply cannot happen), or both.

I think the Butenhof definition is especially vague, it specifies a method for achieving the “safe for multithreading” guarantee, not the guarantee itself. And the method itself somewhat implies “safe for recursion”, but it isn’t explicitly stated.

Any tips for Beijing BTW? I’m flying there tomorrow to go to PODS 2007…

]]> By: Kragen Sitaker http://www.thinkingparallel.com/2007/06/08/the-most-overused-word-in-parallel-programming-reentrancy/#comment-12036 Kragen Sitaker Fri, 08 Jun 2007 19:54:42 +0000 http://www.thinkingparallel.com/2007/06/08/the-most-overused-word-in-parallel-programming-reentrancy/#comment-12036 In theory, there are at least two versions of the last definition --- a function that is reentrant in the sense that you can call it safely from an interrupt even if it's suspended on the stack is not necessarily reentrant in the sense that you can call it safely from multiple threads, for example if it saves the state of some piece of hardware upon entry and restores it upon exit. I can't think of a realistic example, though. In theory, there are at least two versions of the last definition — a function that is reentrant in the sense that you can call it safely from an interrupt even if it’s suspended on the stack is not necessarily reentrant in the sense that you can call it safely from multiple threads, for example if it saves the state of some piece of hardware upon entry and restores it upon exit. I can’t think of a realistic example, though.

]]>