They're apples and oranges: both fruit but not directly related. Reentrant is a very old and general term that predates the term thread. Code is reentrant when it's safe to interleave executions: suspend one execution at any time and start or continue another one, with all executions producing the same results as if they had been run sequentially.
So you could say that thread safe code is reentrant with respect to execution by multiple threads. But this would be only a partial description. Thread safety also concerns synchronizing access to shared data. Threads give you nice abstractions for this: locks, mutexes, monitors, etc. Reentrant code is more about avoiding shared data. Normally, code labeled reentrant uses no globals and makes no calls to libraries or OS code that use globals. Interrupt handlers, device drivers, other kinds of kernel code, signal handlers, libraries being called by multiple processes, and ancient "terminate and stay resident" MSDOS programs are places where I've seen the term "reentrant" used. When you need to share data or other resources in reentrant code, synchronization methods are generally not standardized. Files used as locks (open() with the "create exclusive" flag in Unix allows only one process to "win", providing a crude binary semaphore) and turning off interrupts for the whole machine are two techniques I've seen. I hope this is useful. On Nov 29, 10:18 am, kumar raja <rajkumar.cs...@gmail.com> wrote: > -- > Regards > Kumar Raja > M.Tech(SIT) > IIT Kharagpur > 10it60...@iitkgp.ac.in -- You received this message because you are subscribed to the Google Groups "Algorithm Geeks" group. To post to this group, send email to algogeeks@googlegroups.com. To unsubscribe from this group, send email to algogeeks+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/algogeeks?hl=en.
