Thu Dec 5 11:24:40 2024
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2015-05-01

HANGOUT

2024-12-05 | 2024-11-05 | 2024-10-05 | 2024-09-05 | 2024-08-05 | 2024-07-05 | 2024-06-05 | 2024-05-05 | 2024-04-05 | 2024-03-05 | 2024-02-05 | 2024-01-05 | 2023-12-05 | 2023-11-05 | 2023-10-05 | 2023-09-05 | 2023-08-05 | 2023-07-05 | 2023-06-05 | 2023-05-05 | 2023-04-05 | 2023-03-05 | 2023-02-05 | 2023-01-05 | 2022-12-05 | 2022-11-05 | 2022-10-05 | 2022-09-05 | 2022-08-05 | 2022-07-05 | 2022-06-05 | 2022-05-05 | 2022-04-05 | 2022-03-05 | 2022-02-05 | 2022-01-05 | 2021-12-05 | 2021-11-05 | 2021-10-05 | 2021-09-05 | 2021-08-05 | 2021-07-05 | 2021-06-05 | 2021-05-05 | 2021-04-05 | 2021-03-05 | 2021-02-05 | 2021-01-05 | 2020-12-05 | 2020-11-05 | 2020-10-05 | 2020-09-05 | 2020-08-05 | 2020-07-05 | 2020-06-05 | 2020-05-05 | 2020-04-05 | 2020-03-05 | 2020-02-05 | 2020-01-05 | 2019-12-05 | 2019-11-05 | 2019-10-05 | 2019-09-05 | 2019-08-05 | 2019-07-05 | 2019-06-05 | 2019-05-05 | 2019-04-05 | 2019-03-05 | 2019-02-05 | 2019-01-05 | 2018-12-05 | 2018-11-05 | 2018-10-05 | 2018-09-05 | 2018-08-05 | 2018-07-05 | 2018-06-05 | 2018-05-05 | 2018-04-05 | 2018-03-05 | 2018-02-05 | 2018-01-05 | 2017-12-05 | 2017-11-05 | 2017-10-05 | 2017-09-05 | 2017-08-05 | 2017-07-05 | 2017-06-05 | 2017-05-05 | 2017-04-05 | 2017-03-05 | 2017-02-05 | 2017-01-05 | 2016-12-05 | 2016-11-05 | 2016-10-05 | 2016-09-05 | 2016-08-05 | 2016-07-05 | 2016-06-05 | 2016-05-05 | 2016-04-05 | 2016-03-05 | 2016-02-05 | 2016-01-05 | 2015-12-05 | 2015-11-05 | 2015-10-05 | 2015-09-05 | 2015-08-05 | 2015-07-05 | 2015-06-05 | 2015-05-05 | 2015-04-05 | 2015-03-05 | 2015-02-05 | 2015-01-05 | 2014-12-05 | 2014-11-05 | 2014-10-05 | 2014-09-05 | 2014-08-05 | 2014-07-05 | 2014-06-05 | 2014-05-05 | 2014-04-05 | 2014-03-05 | 2014-02-05 | 2014-01-05 | 2013-12-05 | 2013-11-05 | 2013-10-05 | 2013-09-05 | 2013-08-05 | 2013-07-05 | 2013-06-05 | 2013-05-05 | 2013-04-05 | 2013-03-05 | 2013-02-05 | 2013-01-05 | 2012-12-05 | 2012-11-05 | 2012-10-05 | 2012-09-05 | 2012-08-05 | 2012-07-05 | 2012-06-05 | 2012-05-05 | 2012-04-05 | 2012-03-05 | 2012-02-05 | 2012-01-05 | 2011-12-05 | 2011-11-05 | 2011-10-05 | 2011-09-05 | 2011-08-05 | 2011-07-05 | 2011-06-05 | 2011-05-05 | 2011-04-05 | 2011-03-05 | 2011-02-05 | 2011-01-05 | 2010-12-05 | 2010-11-05 | 2010-10-05 | 2010-09-05 | 2010-08-05 | 2010-07-05 | 2010-06-05 | 2010-05-05 | 2010-04-05 | 2010-03-05 | 2010-02-05 | 2010-01-05 | 2009-12-05 | 2009-11-05 | 2009-10-05 | 2009-09-05 | 2009-08-05 | 2009-07-05 | 2009-06-05 | 2009-05-05 | 2009-04-05 | 2009-03-05 | 2009-02-05 | 2009-01-05 | 2008-12-05 | 2008-11-05 | 2008-10-05 | 2008-09-05 | 2008-08-05 | 2008-07-05 | 2008-06-05 | 2008-05-05 | 2008-04-05 | 2008-03-05 | 2008-02-05 | 2008-01-05 | 2007-12-05 | 2007-11-05 | 2007-10-05 | 2007-09-05 | 2007-08-05 | 2007-07-05 | 2007-06-05 | 2007-05-05 | 2007-04-05 | 2007-03-05 | 2007-02-05 | 2007-01-05 | 2006-12-05 | 2006-11-05 | 2006-10-05 | 2006-09-05 | 2006-08-05 | 2006-07-05 | 2006-06-05 | 2006-05-05 | 2006-04-05 | 2006-03-05 | 2006-02-05 | 2006-01-05 | 2005-12-05 | 2005-11-05 | 2005-10-05 | 2005-09-05 | 2005-08-05 | 2005-07-05 | 2005-06-05 | 2005-05-05 | 2005-04-05 | 2005-03-05 | 2005-02-05 | 2005-01-05 | 2004-12-05 | 2004-11-05 | 2004-10-05 | 2004-09-05 | 2004-08-05 | 2004-07-05 | 2004-06-05 | 2004-05-05 | 2004-04-05 | 2004-03-05 | 2004-02-05 | 2004-01-05 | 2003-12-05 | 2003-11-05 | 2003-10-05 | 2003-09-05 | 2003-08-05 | 2003-07-05 | 2003-06-05 | 2003-05-05 | 2003-04-05 | 2003-03-05 | 2003-02-05 | 2003-01-05 | 2002-12-05 | 2002-11-05 | 2002-10-05 | 2002-09-05 | 2002-08-05 | 2002-07-05 | 2002-06-05 | 2002-05-05 | 2002-04-05 | 2002-03-05 | 2002-02-05 | 2002-01-05 | 2001-12-05 | 2001-11-05 | 2001-10-05 | 2001-09-05 | 2001-08-05 | 2001-07-05 | 2001-06-05 | 2001-05-05 | 2001-04-05 | 2001-03-05 | 2001-02-05 | 2001-01-05 | 2000-12-05 | 2000-11-05 | 2000-10-05 | 2000-09-05 | 2000-08-05 | 2000-07-05 | 2000-06-05 | 2000-05-05 | 2000-04-05 | 2000-03-05 | 2000-02-05 | 2000-01-05 | 1999-12-05

Key: Value:

Key: Value:

MESSAGE
DATE 2015-05-02
FROM Ruben Safir
SUBJECT Subject: [NYLXS - HANGOUT] Semephores and what the heck are those things?

http://www.makelinux.net/books/lkd2/ch09lev1sec4

*Linux kernel map in printable PDF* for $4 or €3


< open Table of Content

Team LiB

Previous Section
Next Section


Semaphores

Semaphores in Linux are sleeping locks. When a task attempts to acquire
a semaphore that is already held, the semaphore places the task onto a
wait queue and puts the task to sleep. The processor is then free to
execute other code. When the processes^[3]
holding the
semaphore release the lock, one of the tasks on the wait queue is
awakened so that it can then acquire the semaphore.

^[3] As you will see, multiple processes can simultaneously hold a
semaphore, if desired.

Let's jump back to the door and key analogy. When a person reaches the
door, he can grab the key and enter the room. The big difference lies in
what happens when another dude reaches the door and the key is not
available. In this case, instead of spinning, the fellow puts his name
on a list and takes a nap. When the person inside the room leaves, he
checks the list at the door. If anyone's name is on the list, he goes
over to the first name and gives him a playful jab in the chest, waking
him up and allowing him to enter the room. In this manner, the key
(read: semaphore) continues to ensure that there is only one person
(read: thread of execution) inside the room (read: critical region) at
one time. If the room is occupied, instead of spinning, the person puts
his name on a list (read: wait queue) and takes a nap (read: blocks on
the wait queue and goes to sleep), allowing the processor to go off and
execute other code. This provides better processor utilization than spin
locks because there is no time spent busy looping, but semaphores have
much greater overhead than spin locks. Life is always a trade-off.

You can draw some interesting conclusions from the sleeping behavior of
semaphores:

*

Because the contending tasks sleep while waiting for the lock to
become available, semaphores are well suited to locks that are held
for a long time.

*

Conversely, semaphores are not optimal for locks that are held for
very short periods because the overhead of sleeping, maintaining the
wait queue, and waking back up can easily outweigh the total lock
hold time.

*

Because a thread of execution sleeps on lock contention, semaphores
can be obtained only in process context because interrupt context is
not schedulable.

*

You can (although you may not want to) sleep while holding a
semaphore because you will not deadlock when another process
acquires the same semaphore. (It will just go to sleep and
eventually let you continue.)

*

You cannot hold a spin lock while you acquire a semaphore, because
you might have to sleep while waiting for the semaphore, and you
cannot sleep while holding a spin lock.

These facts highlight the uses of semaphores versus spin locks. In most
uses of semaphores, there is little choice as to what lock to use. If
your code needs to sleep, which is often the case when synchronizing
with user-space, semaphores are the sole solution. It is often easier,
if not necessary, to use semaphores because they allow you the
flexibility of sleeping. When you do have a choice, the decision between
semaphore and spin lock should be based on lock hold time. Ideally, all
your locks should be held as briefly as possible. With semaphores,
however, longer lock hold times are more acceptable. Additionally,
unlike spin locks, semaphores do not disable kernel preemption and,
consequently, code holding a semaphore can be preempted. This means
semaphores do not adversely affect scheduling latency.

A final useful feature of semaphores is that they can allow for an
arbitrary number of simultaneous lock holders. Whereas spin locks permit
at most one task to hold the lock at a time, the number of permissible
simultaneous holders of semaphores can be set at declaration time. This
value is called the usage count or simply the count. The most common
value is to allow, like spin locks, only one lock holder at a time. In
this case, the count is equal to one and the semaphore is called either
a binary semaphore (because it is either held by one task or not held at
all) or a mutex (because it enforces mutual exclusion). Alternatively,
the count can be initialized to a nonzero value greater than one. In
this case, the semaphore is called a counting semaphore, and it allows
at most count holders of the lock at a time. Counting semaphores are not
used to enforce mutual exclusion because they allow multiple threads of
execution in the critical region at once. Instead, they are used to
enforce limits in certain code. They are not used much in the kernel. If
you use a semaphore, you almost assuredly want to use a mutex (a
semaphore with a count of one).

Semaphores were formalized by Edsger Wybe Dijkstra^[4]
in 1968 as a
generalized locking mechanism. A semaphore supports two atomic
operations, P() and V(), named after the Dutch word Proberen, to test
(literally, to probe), and the Dutch word Verhogen, to increment. Later
systems called these methods down() and up(), respectively, and so does
Linux. The down() method is used to acquire a semaphore by decrementing
the count by one. If the new count is zero or greater, the lock is
acquired and the task can enter the critical region. If the count is
negative, the task is placed on a wait queue and the processor moves on
to something else. These names are used as verbs: You down a semaphore
to acquire it. The up() method is used to release a semaphore upon
completion of a critical region. This is called upping the semaphore.
The method increments the count value; if the semaphore's wait queue is
not empty, one of the waiting tasks is awakened and allowed to acquire
the semaphore.

^[4] Dr. Dijkstra (1930-2002) is one of the most accomplished
computer scientists in the (admittedly brief) history of computer
scientists. His numerous contributions include work in OS design,
algorithm theory, and the concept of semaphores. He was born in
Rotterdam, The Netherlands, and taught at the University of Texas
for 15 years. He is probably not happy with the large number of GOTO
statements in the Linux kernel, however.


Creating and Initializing Semaphores

The semaphore implementation is architecture dependent and defined in
. The struct semaphore type represents semaphores.
Statically declared semaphores are created via

static DECLARE_SEMAPHORE_GENERIC(name, count)


where name is the variable's name and count is the usage count of the
semaphore. As a shortcut to create the more common mutex, use

static DECLARE_MUTEX(name);


where, again, name is the variable name of the semaphore. More
frequently, semaphores are created dynamically, often as part of a
larger structure. In this case, to initialize a dynamically created
semaphore to which you have only an indirect pointer reference, use

sema_init(sem, count);


where sem is a pointer and count is the usage count of the semaphore.
Similarly, to initialize a dynamically created mutex, you can use

init_MUTEX(sem);


I do not know why the "mutex" in init_MUTEX() is capitilized or why the
"init" comes first here but second in sema_init(). I do know, however,
that it looks dumb and I apologize for the inconsistency. I hope,
however, that after you've read Chapter 7
, the kernel's
symbol naming does not shock anyone.


Using Semaphores

The function down_interruptible() attempts to acquire the given
semaphore. If it fails, it sleeps in the TASK_INTERRUPTIBLE state.
Recall from Chapter 3
that this process
state implies that a task can be awakened with a signal, which is
generally a good thing. If the task receives a signal while waiting for
the semaphore, it is awakened and down_interruptible() returns -EINTR.
Alternatively, the function down() places the task in the
TASK_UNINTERRUPTIBLE state if it sleeps. You most likely do not want
this because the process waiting for the semaphore does not respond to
signals. Therefore, use of down_interruptible() is much more common than
down(). Yes, again, the naming is not ideal.

You can use down_trylock() to try to acquire the given semaphore with
blocking. If the semaphore is already held, the function immediately
returns nonzero. Otherwise, it returns zero and you successfully hold
the lock.

To release a given semaphore, call up(). Consider an example:

/* define and declare a semaphore, named mr_sem, with a count of one */
static DECLARE_MUTEX(mr_sem);

/* attempt to acquire the semaphore ... */
if (down_interruptible(&mr_sem)) {
/* signal received, semaphore not acquired ... */
}

/* critical region ... */

/* release the given semaphore */
up(&mr_sem);


A complete listing of the semaphore methods is in Table 9.5
.


Table 9.5. Listing of Semaphore Methods

Method



Description

sema_init(struct semaphore *, int)



Initializes the dynamically created semaphore to the given count

init_MUTEX(struct semaphore *)



Initializes the dynamically created semaphore with a count of one

init_MUTEX_LOCKED(struct semaphore *)



Initializes the dynamically created semaphore with a count of zero (so
it is initially locked)

down_interruptible(struct semaphore *)



Tries to acquire the given semaphore and enter interruptible sleep if it
is contended

down(struct semaphore *)



Tries to acquire the given semaphore and enter uninterruptible sleep if
it is contended

down_trylock(struct semaphore *)



Tries to acquire the given semaphore and immediately return nonzero if
it is contended

up(struct semaphore *)



Releases the given semaphore and wakes a waiting task, if any


  1. 2015-05-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Great Article on Software Concordance program writing
  2. 2015-05-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Excellent article on Virtual Paging and OS memory
  3. 2015-05-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Semephores and what the heck are those things?
  4. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] digital advert fraud
  5. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Go Language tutorials
  6. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Journal Club meeting
  7. 2015-05-03 Elfen Magix <elfen_magix-at-yahoo.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  8. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  9. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: Journal Article
  10. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  11. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  12. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  13. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  14. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  15. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  16. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Movie of the week
  17. 2015-05-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  18. 2015-05-03 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  19. 2015-05-04 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  20. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Journal Club meeting
  21. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: a second look at storage and pointer fundamentals
  22. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Kernel Scheduling and wait queues
  23. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [Perlweekly] #197 - YAPC::EU Master classes - talks - hackathons
  24. 2015-05-04 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [ Khal Tiferes Yaakov ] Lag B'Omer in Passaic
  25. 2015-05-05 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Nice possible project for NYLXS or others
  26. 2015-05-06 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Tomorrow: You're hosting "Journal Club Meetings"
  27. 2015-05-08 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Things to study over the summer
  28. 2015-05-08 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Things to study over the summer
  29. 2015-05-08 adrba-at-nyct.net Re: [NYLXS - HANGOUT] Things to study over the summer
  30. 2015-05-08 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Re: Kernel Scheduler and wiat queues
  31. 2015-05-09 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Movies of the Week
  32. 2015-05-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] scheduler Slides
  33. 2015-05-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: [LIU Comp Sci] scheduler Slides
  34. 2015-05-11 Ruben Safir <ruben.safir-at-my.liu.edu> Subject: [NYLXS - HANGOUT] Re: [LIU Comp Sci] scheduler Slides
  35. 2015-05-11 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: [LIU Comp Sci] scheduler Slides
  36. 2015-05-12 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] jobs
  37. 2015-05-12 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Job sound like this evenings lectures
  38. 2015-05-12 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] LAMP Jobs
  39. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] April Journal is Available
  40. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Tomorrow: You and 256 others are going to "Btrfs"
  41. 2015-05-13 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [member-at-linkedin.com: RE: April Journal is Available]
  42. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [mrbrklyn-at-panix.com: Re: [NYLXS - HANGOUT] Things to study over the
  43. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Malloc systemtap probes: an example
  44. 2015-05-13 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Stackiq - Educational Program
  45. 2015-05-14 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Weekly Education Meeting
  46. 2015-05-17 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] ssh hack
  47. 2015-05-18 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [manjaro-general] Manjaro 0.8.13-rc1 released
  48. 2015-05-18 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [Perlweekly] #199 - Rust 1.0 is out!
  49. 2015-05-18 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Check This Out
  50. 2015-05-18 adrba-at-nyct.net Re: [NYLXS - HANGOUT] Check This Out
  51. 2015-05-18 Elfen Magix <elfen_magix-at-yahoo.com> Re: [NYLXS - HANGOUT] Check This Out
  52. 2015-05-18 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [jkeen-at-verizon.net: ny.pm Technical Meeting Wed May 20 6:15 pm]
  53. 2015-05-19 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Check This Out
  54. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] copyright vrs free speach on utube
  55. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Check This Out
  56. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Check This Out
  57. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Weapons of Mass Destruction my ass
  58. 2015-05-19 Robert Menes <viewtiful.icchan-at-gmail.com> Re: [NYLXS - HANGOUT] Check This Out
  59. 2015-05-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] NYLXS
  60. 2015-05-19 Rick Moen <rick-at-linuxmafia.com> Re: [NYLXS - HANGOUT] Check This Out
  61. 2015-05-20 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Check This Out
  62. 2015-05-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Free Software Business
  63. 2015-05-25 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Summer NYLXS Study Schedule
  64. 2015-05-26 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] C++ maheim
  65. 2015-05-26 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: IEEE NY Meeting Announcement
  66. 2015-05-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Plane Hacking
  67. 2015-05-27 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Oracle attach on Android Copyright
  68. 2015-05-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] adblock is legal... who knew?
  69. 2015-05-28 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] Steeley Dan in NYC
  70. 2015-05-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: privacy and data security
  71. 2015-05-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Please give to the Houston Relief Fund
  72. 2015-05-28 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Please give to the Houston Relief Fund
  73. 2015-05-28 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [ruben-at-www.mrbrklyn.com: Linux 1 Book]
  74. 2015-05-29 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Minting Money with Free software
  75. 2015-05-31 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] anyone familiar with STM?

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!