Semaphore

[SaNtosh kuLkarni]

Hi Guys,

Thanks for the replies and your interest and your time :) :) cause i did
not know if it was a valid doubt
, ya my doubt was on how to handle situations like this...i would also like
to add few more doubts/append/ to my previous question and make the
question more clear..

You have thread/process which has acquired a sema lock/sem down and you
kill tat thread or kswapd [[ i would also like to know if its possible
gracefully and will that render your system safe ]] say a #bug in your code
 before it does a sema up/post.I just had this doubt and am considering a
possible scenario for code flow/unit test. And also if not a issue how
would a user space code would handle this deadlock situation ....signal
handler for sem lock release may be??!

Thanks

On Wed, Feb 22, 2012 at 8:01 PM, Sri Ram Vemulpali
<sri.ram.gmu06 at gmail.com>wrote:

> The original question was "how can one can handle safe release of
> semaphore when a process dies after acquiring semaphore?". This is
> causing the semaphore to be in acquired state, resulting other
> processes to wait on it.
>
> Regardless of file handling in the kernel, how kernel cleans up the
> resources held up by the process this question is more specific to
> locking mechanism.
>
> Semaphore design and solution has inherent problem of determining who
> held the lock. If the owner ship of the lock is unknown it would be
> easy to release the lock if process dies after acquiring the lock. To
> overcome this problem, mutex was designed as solution. Mutex provides
> the ownership of the lock. So, whenever the lock is held by thread,
> ownership is assigned to that thread. This way one can know which when
> to release lock if in event of thread dies. In POSIX there are mutex
> handlers called push and pop handler. Check POSIX API.
>
> Regards,
> Sri.
>
>
>
>
>
>
> On Wed, Feb 22, 2012 at 7:11 AM, Kristof Provost <kristof at sigsegv.be>
> wrote:
> > On 2012-02-22 11:53:12 (+0000), Anuz Pratap Singh Tomar <
> chambilkethakur at gmail.com> wrote:
> >> On Wed, Feb 22, 2012 at 9:48 AM, Kristof Provost <kristof at sigsegv.be>
> wrote:
> >>
> >> > On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel <
> zertsekel at gmail.com>
> >> > wrote:
> >> > > On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands <dhylands at gmail.com>
> >> > wrote:
> >> > > > I'm assuming that the semaphore is one which is held across
> multiple
> >> > > > calls into the kernel, otherwise you don't have an issue in the
> first
> >> > > > place, unless there is a bug on the kernel side of things which
> >> > > > actually caused the process to terminate.
> >> > >
> >> > > Ok, but what happens if things go wrong?
> >> > > For example, it driver exists abnormally (segmentation fault or
> >> > something)?
> >> > > Anyway, it seems very strange that the responsibility is of a driver
> >> > alone!
> >> > > There is the *kernel* in the system to take care of abnormal
> >> > > situation, not the exit function of a driver...
> >> > >
> >> > The driver is part of the kernel. If it dies the whole kernel can
> >> > (perhaps even should) die.
> >> >
> >> > There are systems, like Minix, where drivers don't run in kernel mode
> >> > and where a crashing driver won't take the system down.
> >> > There are advantages and disadvantages to that approach.
> >> > See http://en.wikipedia.org/wiki/Microkernel
> >> >
> >> >
> >> I am curious though if userspace gets segmentation fault, which is
> SIGSEGV,
> >> kernel should be the one sending that to user space. And while sending
> >> SIGSEGV, it must be doing some exit cleanup, wherein it frees all
> >> resources. However unlike memory, i haven't seen exit code which frees
> lock
> >> as well?
> >>
> > You're talking about a user space application crashing, Konstantin was
> > talking about crashes in kernel space. These are two very different
> > things.
> >
> > In either case we're talking about a lock inside the kernel.
> >
> > For the first case:
> > Imagine a driver which only one app can use at a time (perhaps a serial
> > port). The kernel will take a lock when the user space app open()s the
> > device node and release it when it close()s.
> > If the app segfaults in between the open() and close() the lock will
> > still get released. The kernel always cleans up open files for stopped
> > processes, regardless of how they stop. During this cleanup the kernel
> > will close() the device node, and as a result the driver will release
> > the lock.
> >
> > In the second case:
> > A kernel thread has a lock held, for whatever reason. It can be
> > terminated for a variety of reasons (*all* of them bugs or hardware
> > problems). For example it fails a BUG_ON check, or causes a fault by
> > accessing unmapped memory. In that case the oops handler will terminate
> > the thread, but in that case the lock will still be held, and never
> > unlocked.
> > This results in an incorrect state of the kernel! Some things might
> > still work, others will be broken.
> >
> > Regards,
> > Kristof
> >
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> --
> Regards,
> Sri.
>



-- 
*Regards,
Santosh Kulkarni*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120223/47bf0a0f/attachment.html